* What's in git.git (stable)
@ 2006-12-13 21:35 Junio C Hamano
2006-12-13 22:37 ` Andy Parkins
` (3 more replies)
0 siblings, 4 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-13 21:35 UTC (permalink / raw)
To: git; +Cc: linux-kernel
We have a handful fixes on 'maint'; I will be cutting v1.4.4.3 by
the end of the week.
On the 'master' front, this round has many topics (most of which
have been cooking in the 'next' branch) merged since the last
announcement.
- Johannes Schindelin's built-in shortlog is in.
- Johannes Schindelin's built-in 'RCS merge replacement' is
in. Hopefully this would make merge-recursive more portable
and faster.
- Shawn Pearce and Johannes Schindelin spotted and fixed a few
corner cases in merge-recursive.
- Updates to gitk from Paul Mackerras to fix longstanding menu
issues on Mac OS X.
- Eric Wong fixed use of rerere in many places.
- Eric also has quite a few fixes to git-svn.
- Nico updated 'git-add' to really mean 'add contents', not
'add to the set of tracked paths'. Also updated was the
documentation for 'git commit' to make it easier to teach new
people after a long discussion.
- Lars Hjemli taught 'git-branch' to rename branches.
- Andy Parkins taught 'git-branch' to be colorful.
- Robin Rosenberg improved cvsexportcommit for unusual
pathnames.
- 'git push $URL :refs/tags/that' (notice the colon) can be
used to delete 'that' tag from the remote repository; this
needs the latest git on both ends.
- branch."master".{remote,merge} configuration items are set up
by 'git-clone', thanks to Andy Parkins.
- 'git-commit' gives 'diff --summary' output to remind mode
changes and added/deleted files.
- 'git-diff --numstat' matches 'git-apply --numstat' when
talking about binary changes.
- 'git-merge' is now a first class UI, not just a mere driver
for strategies.
I am hoping that we can start a stabilization cycle for v1.5.0
based on what we have in 'master'. The theme is "usability and
teachability".
Things that need to be done to complete what have been merged to
'master' are:
- 'git-rm' needs to be fixed up as Linus outlined; remove
working tree file and index entry but have a sanity check to
make sure the working tree file match the index and HEAD.
- 'git-branch' may need to be taught about renaming the
matching per-branch configuration at the same time.
- 'git-merge-file' needs to be documented and linked from
git.txt.
- 'git-clone' probably should be updated to use wild-card in
remote.origin.fetch, instead of listing all the branches it
found when the clone was made.
- tutorials and other Porcelain documentation pages need to be
updated to match the updated 'git-add' and 'git-rm' (to be
updated), and their description should be made much less
about implementation; they should talk in terms of end-user
workflows. I will send a draft for 'git diff' out later, but
somebody needs a full sweep on Porcelain-ish documentation.
- 'git diff --index' patch should be reverted (already done in
'next'), although we may have to come up with a better
wording for --cached.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.4.4.2.
Alex Riesen (1):
Clarify fetch error for missing objects.
Brian Gernhardt (1):
Move Fink and Ports check to after config file
Chris Wright (1):
no need to install manpages as executable
Eric Wong (2):
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
Jim Meyering (1):
Don't use memcpy when source and dest. buffers may overlap
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes in Perl v5.8.x
Shawn O. Pearce (1):
Make sure the empty tree exists when needed in merge-recursive.
* The 'master' branch has these since the last announcement.
Alex Riesen (3):
git-blame: fix rev parameter handling.
Make perl/ build procedure ActiveState friendly.
Clarify fetch error for missing objects.
Andreas Ericsson (2):
ls-files: Give hints when errors happen.
git-diff: Introduce --index and deprecate --cached.
Andy Parkins (6):
Use .git/config for storing "origin" shortcut repository
Document git-repo-config --bool/--int options.
De-emphasise the symbolic link documentation.
Explicitly add the default "git pull" behaviour to .git/config on clone
Colourise git-branch output
Allow subcommand.color and color.subcommand color configuration
Brian Gernhardt (1):
Move Fink and Ports check to after config file
Chris Wright (1):
no need to install manpages as executable
David Miller (1):
Pass -M to diff in request-pull
Eric Wong (21):
git-svn: use ~/.subversion config files when using SVN:: libraries
git-svn: enable delta transfers during fetches when using SVN:: libs
git-svn: update tests for recent changes
git-svn: error out when the SVN connection fails during a fetch
git-svn: fix output reporting from the delta fetcher
git-svn: color support for the log command
git-svn: documentation updates
git-svn: fix multi-init
git-svn: avoid fetching files twice in the same revision
git-svn: avoid network timeouts for long-running fetches
git-svn: extra error check to ensure we open a file correctly
git-svn: use do_switch for --follow-parent if the SVN library supports it
rerere: add clear, diff, and status commands
rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
git-svn: enable logging of information not supported by git
git-svn: allow dcommit to take an alternate head
git-svn: correctly display fatal() error messages
git-svn: correctly handle packed-refs in refs/remotes/
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
git-svn: correctly handle "(no author)" when using an authors file
Han-Wen Nienhuys (1):
ident.c: Trim hint printed when gecos is empty.
J. Bruce Fields (4):
cvs-migration: improved section titles, better push/commit explanation
Documentation: reorganize cvs-migration.txt
Documentation: update git-clone man page with new behavior
Documentation: simpler shared repository creation
Jakub Narebski (4):
gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
git-clone: Rename --use-immingled-remote option to --no-separate-remote
Document git-diff whitespace flags -b and -w
gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view
Jeff King (1):
shortlog: fix segfault on empty authorname
Jim Meyering (2):
Set permissions of each new file before "cvs add"ing it.
Don't use memcpy when source and dest. buffers may overlap
Johannes Schindelin (18):
Build in shortlog
shortlog: do not crash on parsing "[PATCH"
shortlog: read mailmap from ./.mailmap again
shortlog: handle email addresses case-insensitively
shortlog: fix "-n"
shortlog: use pager
sha1_object_info(): be consistent with read_sha1_file()
xdiff: add xdl_merge()
xdl_merge(): fix an off-by-one bug
xdl_merge(): fix thinko
git-mv: search more precisely for source directory in index
diff -b: ignore whitespace at end of line
xdl_merge(): fix and simplify conflict handling
cvs-migration document: make the need for "push" more obvious
Add builtin merge-file, a minimal replacement for RCS merge
merge-file: support -p and -q; fix compile warnings
Get rid of the dependency on RCS' merge program
merge-recursive: add/add really is modify/modify with an empty base
Josef Weidendorfer (1):
Add branch.*.merge warning and documentation update
Junio C Hamano (45):
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
merge: allow merging into a yet-to-be-born branch.
Store peeled refs in packed-refs (take 2).
git-fetch: reuse ls-remote result.
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: allow glob pattern in refspec
Allow git push to delete remote ref.
git-shortlog: fix common repository prefix abbreviation.
git-shortlog: make common repository prefix configurable with .mailmap
git-commit: show --summary after successful commit.
git-fetch: allow forcing glob pattern in refspec
fetch-pack: do not barf when duplicate re patterns are given
git-merge: tighten error checking.
git-merge: do not leak rev-parse output used for checking internally.
cvsimport: style fixup.
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
git-merge: fix confusion between tag and branch
xmerge: make return value from xdl_merge() more usable.
merge-recursive: use xdl_merge().
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
read-tree: further loosen "working file will be lost" check.
Loosen "working file will be lost" check in Porcelain-ish
read-tree: document --exclude-per-directory
git-reset to remove "$GIT_DIR/MERGE_MSG"
git-merge: squelch needless error message.
git-merge: fix "fix confusion between tag and branch" for real
Fix perl/ build.
git-rerere: add 'gc' command.
Documentation/git-commit: rewrite to make it more end-user friendly.
git-commit: allow --only to lose what was staged earlier.
shortlog: remove "[PATCH]" prefix from shortlog output
shortlog: fix segfault on empty authorname
diff --numstat: show binary with '-' to match "apply --numstat"
add test case for recursive merge
git-push: document removal of remote ref with :<dst> pathspec
git merge: reword failure message.
spurious .sp in manpages
git-push: accept tag <tag> as advertised.
send-pack: tighten checks for remote names
branch --color: change default color selection.
config documentation: group color items together.
Lars Hjemli (3):
git-branch: add options and tests for branch renaming
rename_ref: use lstat(2) when testing for symlink
git-branch: let caller specify logmsg
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes in Perl v5.8.x
Michael Loeffler (1):
git-fetch: ignore dereferenced tags in expand_refs_wildcard
Nicolas Pitre (4):
builtin git-shortlog is broken
pack-objects: remove redundent status information
make 'git add' a first class user friendly interface to the index
change the unpack limit treshold to a saner value
Paul Mackerras (1):
gitk: Fix enabling/disabling of menu items on Mac OS X
René Scharfe (1):
shortlog: remove range check
Robin Rosenberg (1):
Make cvsexportcommit work with filenames with spaces and non-ascii characters.
Sean Estabrooks (1):
Update documentation to remove incorrect GIT_DIFF_OPTS example.
Shawn O. Pearce (17):
Teach git-completion.bash how to complete git-merge.
Hide plumbing/transport commands from bash completion.
Teach bash how to complete options for git-name-rev.
Add current branch in PS1 support to git-completion.bash.
Teach bash how to complete git-format-patch.
Teach bash how to complete git-cherry-pick.
Teach bash how to complete git-rebase.
Teach bash about git log/show/whatchanged options.
Support bash completion of refs/remote.
Teach bash about git-repo-config.
Support --strategy=x completion in addition to --strategy x.
Cache the list of merge strategies and available commands during load.
Teach bash about git-am/git-apply and their whitespace options.
Teach bash how to complete long options for git-commit.
Fix broken bash completion of local refs.
Make sure the empty tree exists when needed in merge-recursive.
Remove uncontested renamed files during merge.
Uwe Zeisberger (1):
Fix documentation copy&paste typo
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
@ 2006-12-13 22:37 ` Andy Parkins
2006-12-13 22:48 ` Jakub Narebski
` (3 more replies)
2006-12-16 9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
` (2 subsequent siblings)
3 siblings, 4 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-13 22:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
> I am hoping that we can start a stabilization cycle for v1.5.0
> based on what we have in 'master'. The theme is "usability and
> teachability".
This is what I have in my "niggles" list. These are surface level things that
I think are easy to fix. A large part of the scariness is (I think) git's
unfriendly output. Too many messages require understanding of git internals.
The major barrier to implementing these sorts of changes is, I think, worries
about users of the output of these commands in scripts. I say: screw them,
porcelain is there for the breaking :-)
* git-fetch has to be in working root. If I can do git-push from anywhere in
my tree, why can't I do git-fetch?
* git-reset has to be in working root. If you typically sit in, say "src/",
it's annoying to have to change directory to do a reset.
* git-commit doesn't (generally) have output - after a commit, it's difficult
to know if anything happened. Get users used to the idea of hashes to
identify commits by telling them which one they just made. Tell them if
they made a branch as well, which branch they are now on.
* git-init-db says "defaulting to local storage area", as if that is
meant to be a helpful message
* git-revert should be called git-invert. It doesn't remove a change
from history, it simply applies another commit that does the
opposite of whatever commit you are "revert"ing. That's an inversion.
* git-merge output is horrible - this affects git-pull, git-rebase,
and git-cherry-pick. Issuing "fatal" errors and then carrying on is very
confusing. Errors in merges appear multiple times. The files upon which
which there is a conflict are spread throughout the output. Most of the
output is not relevant to an average user.
* git-apply output is horrible. It says a few things about whitespace on
stdin then just finishes. When it succeeds. When it fails, it just says
failed, it doesn't say why a particular hunk failed.
* git-branch is not verbose enough when creating a new branch, for a new user
a little reassurance that what they meant to happen has happened would be
nice.
* git-commit without "-a" and without an "update-index" says "nothing
to commit", which isn't an adequate message to help a user who hasn't
realised they need to update the index
* git-rebase --skip requires that the offending file be clean with
git-checkout HEAD file
before the skip will work. Why? The fact of the skip is enough
knowledge for rebase to know that I don't care if the merge is lost
* git-rebase/git-cherry-pick/git-reset/etc should all tell the user that they
need to run git-prune to tidy up after themselves.
* git-add has no output, whether it works or not
* git-cat-file is badly named. git-cat-object would be slightly
better.
* git-fetch output is confusing:
remote: Generating pack...
remote: Done counting 189146 objects.
remote: Result has 186566 objects.
remote: Deltifying 186566 objects.
remote: 100% (186566/186566) done
Unpacking 186566 objects
24% (44792/186566) done
Some questions from the point of view of a newbie: what is a pack? what is
an object? Why is the remote counting them? Which remote am I reading
from? What am I fetching? What is "Deltifying"? How much data do I have
to download (number of objects doesn't tell me). How long has this taken?
How long is left to go?
* Similar things can be said about git-clone
* Similar things can be said about git-push
* git-show-branch output is cryptic.
* In general the principle for messages should be the same as for
presentations:
- say what you're going to do
- do it
- say what you did
So for example, "git-branch newbranch existingbranch" would say
Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
- created branch "newbranch"
- your working branch is "existingbranch"
Rather than the nothing that it currently outputs.
* It would be really nice to be able to do an arbitrary checkout, rather than
having to make a branch for it. Then I could do
git-checkout remotes/origin/master && make
(obviously committing with a non-branch HEAD would be prevented)
* git-verify-tag would be nicer as a switch to git-tag
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 22:37 ` Andy Parkins
@ 2006-12-13 22:48 ` Jakub Narebski
2006-12-14 9:27 ` Andy Parkins
2006-12-13 23:31 ` Junio C Hamano
` (2 subsequent siblings)
3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-13 22:48 UTC (permalink / raw)
To: git
Andy Parkins wrote:
> This is what I have in my "niggles" list. These are surface level things that
> I think are easy to fix. A large part of the scariness is (I think) git's
> unfriendly output. Too many messages require understanding of git internals.
Nice list, although I'd rather add extra output only if command is used
with -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet
(or -s/--silent) option to be used in scripts. I'm partial to --verbose
solution, as advanced users are not interested in any output; they know
the commands, and want them to be fast. C.f GNU tar: it outputs something
only with -v/--verbose option.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 22:48 ` Jakub Narebski
@ 2006-12-14 9:27 ` Andy Parkins
2006-12-14 9:36 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 9:27 UTC (permalink / raw)
To: git
On Wednesday 2006 December 13 22:48, Jakub Narebski wrote:
> Nice list, although I'd rather add extra output only if command is used
> with -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet
> (or -s/--silent) option to be used in scripts. I'm partial to --verbose
I'd rather have the scripts requiring "--quiet"; because otherwise it's
another switch for a newbie to guess at. However, I don't think that
switches is the answer. Output for these porcelain-level commands is not
structured enough to be used in scripts anyway (e.g. git-pull), but what it
does output is a confusing lump.
> solution, as advanced users are not interested in any output; they know
> the commands, and want them to be fast. C.f GNU tar: it outputs something
> only with -v/--verbose option.
tar is doing a considerably less complicated sequence of operations than many
of git's commands, so I don't think that's a fair comparison.
Also; I don't think "experts" should care about the extra output - I can't
imagine that an extra few lines of text is going to slow git down. Further,
I think the problem in most cases is that git outputs _too much_. Also, I'm
not imagining that "git-add ." would list every file that it added - who is
that going to help? It should say "added X files to index" or similar. You
surely can't be arguing that that slows down your expert workflow?
I believe that a good set of output will be useful to both newbies and experts
alike. The idea that experts don't like to know what's going on is simply
not true. The idea that newbies want to see every file listed and every
operation described is simply not true.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 9:27 ` Andy Parkins
@ 2006-12-14 9:36 ` Shawn Pearce
2006-12-14 10:03 ` Andy Parkins
2006-12-14 17:06 ` Nicolas Pitre
0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 9:36 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> wrote:
> I think the problem in most cases is that git outputs _too much_. Also, I'm
> not imagining that "git-add ." would list every file that it added - who is
> that going to help? It should say "added X files to index" or similar. You
> surely can't be arguing that that slows down your expert workflow?
git-commit-tree's "committing initial tree" and git-init-db's
"defaulting to local storage area" are both probably too verbose
and should just get removed.
The progress meters in git-pack-objects that you see during clone,
repack, fetch and push at least keep the user amused. I do read
the output of repack every so often, but in general I don't care
about the output of clone, fetch or push - all I care about is
that my objects got to the remote system and were accepted, or not.
Which means that at least for me the output could be reduced down
to just the bandwidth transfer meter, for really slow links.
But I'm not sure that git-add should output anything. Last I checked
the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
files into a directory. Likewise I don't think that knowing that
6781 files were added is useful, what if it should have really been
6782 files? I'm unlikely to know, care, or realize it.
Your niggle list (is that what you called it) has been useful
fodder for discussion. I'm glad you took the time to write it up,
and to argue it so well on the list. There's a number of items on
it that I'd like to see happen too; enough that I may code some of
them if nobody beats me to it.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 9:36 ` Shawn Pearce
@ 2006-12-14 10:03 ` Andy Parkins
2006-12-14 17:06 ` Nicolas Pitre
1 sibling, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 10:03 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 09:36, Shawn Pearce wrote:
> But I'm not sure that git-add should output anything. Last I checked
> the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
> files into a directory. Likewise I don't think that knowing that
> 6781 files were added is useful, what if it should have really been
> 6782 files? I'm unlikely to know, care, or realize it.
That's a very particular example you've picked out there. Of course the user
won't know if it should be 6781 or 6782; they might know if it should have
been 2 or 10 though; 0 or 100. In your example, output like "about six and a
half thousand", would probably be perfectly useful, but why not just output
the number?
> Your niggle list (is that what you called it) has been useful
> fodder for discussion. I'm glad you took the time to write it up,
> and to argue it so well on the list. There's a number of items on
> it that I'd like to see happen too; enough that I may code some of
> them if nobody beats me to it.
I'm glad it was useful. I never know how many disclaimers to put on these
things. I always feel that every message I write should begin with "I love
git and use it every day, so please don't take this the wrong way, but..."
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 9:36 ` Shawn Pearce
2006-12-14 10:03 ` Andy Parkins
@ 2006-12-14 17:06 ` Nicolas Pitre
2006-12-15 14:28 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Parkins, git
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> But I'm not sure that git-add should output anything. Last I checked
> the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
> files into a directory. Likewise I don't think that knowing that
> 6781 files were added is useful, what if it should have really been
> 6782 files? I'm unlikely to know, care, or realize it.
git-add -v does output added files already.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 17:06 ` Nicolas Pitre
@ 2006-12-15 14:28 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 14:28 UTC (permalink / raw)
To: git
Nicolas Pitre wrote:
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
>
>> But I'm not sure that git-add should output anything. Last I checked
>> the 'mv' command in Linux doesn't say "Move 5 files" when I move 5
>> files into a directory. Likewise I don't think that knowing that
>> 6781 files were added is useful, what if it should have really been
>> 6782 files? I'm unlikely to know, care, or realize it.
>
> git-add -v does output added files already.
Ha! Now only get it to accept --verbose as long alternative to -v option,
and add -v/--verbose option to other similar commands (git-mv for example).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 22:37 ` Andy Parkins
2006-12-13 22:48 ` Jakub Narebski
@ 2006-12-13 23:31 ` Junio C Hamano
2006-12-13 23:52 ` Peter Baumann
` (4 more replies)
2006-12-14 0:22 ` Johannes Schindelin
2006-12-14 23:03 ` Shawn Pearce
3 siblings, 5 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-13 23:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> The major barrier to implementing these sorts of changes is, I
> think, worries about users of the output of these commands in
> scripts. I say: screw them, porcelain is there for the
> breaking :-)
I like that ;-).
Thanks for the list. I'll comment only on no brainers. Things
I cannot decide to agree or disagree are not mentioned in this
message.
> * git-fetch has to be in working root. If I can do git-push
> from anywhere in my tree, why can't I do git-fetch?
> * git-reset has to be in working root. If you typically sit
> in, say "src/", it's annoying to have to change directory to
> do a reset.
> * git-verify-tag would be nicer as a switch to git-tag
True and true and true; let's make them happen.
> * git-commit doesn't (generally) have output - after a
> commit, it's difficult to know if anything happened. Get
> users used to the idea of hashes to identify commits by
> telling them which one they just made.
I am moderately against making a command verbosely report when
it did exactly what it was told to do, _unless_ the command is
expected to take longer than other commands in git suite, or it
is something the user rarely runs.
> * git-branch is not verbose enough when creating a new
> branch, for a new user a little reassurance that what they
> meant to happen has happened would be nice.
The same comment applies here.
However, perhaps you could make lack of "[user] expert = true"
in ~/.gitconfig to trigger more verbose messages that say "yes
sir I did what I was told to do".
Not interested in implementing that myself at all, though.
> Tell them if they
> made a branch as well, which branch they are now on.
I think you are talking about "checkout -b" not commit here;
this might be a borderline (branch creation is less often done
and it might warrant assuring feedback), but I think it still
falls into the "doing exactly what it was told to do" category.
> * git-init-db says "defaulting to local storage area", as if that is
> meant to be a helpful message
It probably used to be back when the original tutorial Linus
wrote was still called tutorial.txt; but I agree that the
message is not helpful anymore.
> * git-merge output is horrible - this affects git-pull,
> git-rebase, and git-cherry-pick. Issuing "fatal" errors and
> then carrying on is very confusing. Errors in merges appear
> multiple times. The files upon which which there is a
> conflict are spread throughout the output. Most of the
> output is not relevant to an average user.
Yes.
> * git-apply output is horrible. It says a few things about
> whitespace on stdin then just finishes. When it succeeds.
> When it fails, it just says failed, it doesn't say why a
> particular hunk failed.
No. It either says patch is corrupt, or a hunk at this line
does not apply. I do not see what more would you would want to
ask it to say.
> * git-commit without "-a" and without an "update-index" says "nothing
> to commit", which isn't an adequate message to help a user who hasn't
> realised they need to update the index
Perhaps.
"\n(hint: 'git add' to stage your changes, or 'git commit --all')\n"
in wt-status.c under "[user] expert = false" mode?
> * git-rebase --skip requires that the offending file be clean with
> git-checkout HEAD file
> before the skip will work. Why? The fact of the skip is enough
> knowledge for rebase to know that I don't care if the merge is lost
As long as your solution does not accidentally lose local,
unrelated changes, changing "git-rebase --skip" to do the needed
clean-up itself for the user would be Ok (I think we would want
to loosen the requirement for starting in a totally clean
working tree in the future).
> * git-rebase/git-cherry-pick/git-reset/etc should all tell
> the user that they need to run git-prune to tidy up after
> themselves.
While I agree the users need to be taught about 'prune', I do
think immediately after running the above commands is exactly
the wrong point to run 'prune'. 'prune' should not be run while
you are busily munging the tip of the branch with rebase and
reset to come up with something that you can call "oh, I am done
with this series for now." Otherwise even lost-found would not
be able to help you.
Also, this sequence creates crufts that need to be pruned:
edit hello.c
git add hello.c
edit hello.c
git add hello.c
I do not think we would want to suggest 'git prune' upon every
'git add'.
> * git-add has no output, whether it works or not
"git add no-such-file" complains, and I think that is adequate.
Now with Nico's 'add means adding contents, not path' change is
in, we _might_ want to differentiate adding a path that was
untracked before and updating the contents, but I think this
again falls into "doing exactly as told" category.
> * git-cat-file is badly named. git-cat-object would be slightly
> better.
Not a Porcelain.
We might want to add a pair of built-in internal aliases though:
[alias]
cat = cat-file -p
less = -p cat-file -p
or have these as samples in template .git/config file.
> * In general the principle for messages should be the same as for
> presentations:
> - say what you're going to do
> - do it
> - say what you did
> So for example, "git-branch newbranch existingbranch" would say
> Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
> - created branch "newbranch"
> - your working branch is "existingbranch"
> Rather than the nothing that it currently outputs.
In general the principle ought to be not to say anything if the
command does exactly what it was told to do successfully, unless
the operation is expected to take longer than other normal
commands in the git suite, or something that is rarely used.
Perhaps under "[user] expert" control.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 23:31 ` Junio C Hamano
@ 2006-12-13 23:52 ` Peter Baumann
2006-12-14 0:16 ` Johannes Schindelin
` (3 subsequent siblings)
4 siblings, 0 replies; 601+ messages in thread
From: Peter Baumann @ 2006-12-13 23:52 UTC (permalink / raw)
To: git
>> * git-branch is not verbose enough when creating a new
>> branch, for a new user a little reassurance that what they
>> meant to happen has happened would be nice.
>
> The same comment applies here.
>
> However, perhaps you could make lack of "[user] expert = true"
> in ~/.gitconfig to trigger more verbose messages that say "yes
> sir I did what I was told to do".
>
> Not interested in implementing that myself at all, though.
>
>> Tell them if they
>> made a branch as well, which branch they are now on.
>
> I think you are talking about "checkout -b" not commit here;
> this might be a borderline (branch creation is less often done
> and it might warrant assuring feedback), but I think it still
> falls into the "doing exactly what it was told to do" category.
>
Yes. checkout -b works. But only _if_ you have read the manpage.
Someone thinking about branching at the current commit would just have
git branch
in mind (so would I). Its not obvious to say
git checkout -b <newbranchname> oldbranch
becouse checkout implies to advance to another version.
-Peter
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 23:31 ` Junio C Hamano
2006-12-13 23:52 ` Peter Baumann
@ 2006-12-14 0:16 ` Johannes Schindelin
2006-12-14 3:32 ` Nicolas Pitre
2006-12-14 8:28 ` Andreas Ericsson
` (2 subsequent siblings)
4 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
Hi,
On Wed, 13 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > * git-cat-file is badly named. git-cat-object would be slightly
> > better.
>
> Not a Porcelain.
>
> We might want to add a pair of built-in internal aliases though:
>
> [alias]
> cat = cat-file -p
> less = -p cat-file -p
>
> or have these as samples in template .git/config file.
I sent a patch which makes "git show" have that functionality, and
frankly, I disagree "less" would be a good name for it. It uses the
_pager_, which is not always "less", and besides, what it does is to show
that particular blob. So obviously, I think my patch is the best approach.
BTW if you now say "git show master:README" it will show _nothing_, not
even an error message.
Ciao,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 0:16 ` Johannes Schindelin
@ 2006-12-14 3:32 ` Nicolas Pitre
2006-12-14 6:29 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 3:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andy Parkins, git
On Thu, 14 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
>
> > We might want to add a pair of built-in internal aliases though:
> >
> > [alias]
> > cat = cat-file -p
> > less = -p cat-file -p
> >
> > or have these as samples in template .git/config file.
>
> I sent a patch which makes "git show" have that functionality, and
> frankly, I disagree "less" would be a good name for it. It uses the
> _pager_, which is not always "less", and besides, what it does is to show
> that particular blob. So obviously, I think my patch is the best approach.
I think your approach is pretty sensible too.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 3:32 ` Nicolas Pitre
@ 2006-12-14 6:29 ` Junio C Hamano
2006-12-14 7:59 ` git-show, was " Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 6:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Johannes Schindelin
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 14 Dec 2006, Johannes Schindelin wrote:
>
>> I sent a patch which makes "git show" have that functionality, and
>> frankly, I disagree "less" would be a good name for it. It uses the
>> _pager_, which is not always "less", and besides, what it does is to show
>> that particular blob. So obviously, I think my patch is the best approach.
>
> I think your approach is pretty sensible too.
I think so too for a few reasons.
* cat-file is a very low level plumbing. Giving it -p was a
mistake made by somebody lazy long time ago back when we were
not all that hot about "user friendliness in Porcelain-ish"
(the option -p was not originally even meant to be the user
level; it was merely a helper feature for verify-tag).
* If we were to call something 'cat' and make a user-level
command, adding the feature to 'show' is a lot more sensible
than cat-file; the former takes more than one args already.
People expect 'cat' to concatenate the arguments. cat-file
doesn't.
* Throwing ls-tree output is the most sensible thing to do at
'cat-file -p <tree-ish>' level, but not at the UI level (Andy
compared ls-tree with 'svn list' today). With 'git show', it
would be more natural to show ls-tree --name-only by default
for tree-ish objects, and control the verbosity level with
command line option.
One minor issue we may need to decide is what to do when show is
given a tag object. Personally I think the current behaviour of
dereferencing it to commit is fine (people who want to see the
tag can always do 'git-verify-tag -v').
^ permalink raw reply [flat|nested] 601+ messages in thread
* git-show, was Re: What's in git.git (stable)
2006-12-14 6:29 ` Junio C Hamano
@ 2006-12-14 7:59 ` Johannes Schindelin
2006-12-14 8:28 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
Hi,
On Wed, 13 Dec 2006, Junio C Hamano wrote:
> One minor issue we may need to decide is what to do when show is
> given a tag object. Personally I think the current behaviour of
> dereferencing it to commit is fine (people who want to see the
> tag can always do 'git-verify-tag -v').
How about adding the command line option "--tag" to git-show, which makes
it only show that tag. I'd also vote for a "--verbose|-v" flag to show the
contents of the tag _before_ showing the referenced object.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: git-show, was Re: What's in git.git (stable)
2006-12-14 7:59 ` git-show, was " Johannes Schindelin
@ 2006-12-14 8:28 ` Junio C Hamano
2006-12-14 10:25 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 8:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 13 Dec 2006, Junio C Hamano wrote:
>
>> One minor issue we may need to decide is what to do when show is
>> given a tag object. Personally I think the current behaviour of
>> dereferencing it to commit is fine (people who want to see the
>> tag can always do 'git-verify-tag -v').
>
> How about adding the command line option "--tag" to git-show, which makes
> it only show that tag. I'd also vote for a "--verbose|-v" flag to show the
> contents of the tag _before_ showing the referenced object.
Sounds sensible. Please make it so.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: git-show, was Re: What's in git.git (stable)
2006-12-14 8:28 ` Junio C Hamano
@ 2006-12-14 10:25 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
Hi,
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Wed, 13 Dec 2006, Junio C Hamano wrote:
> >
> >> One minor issue we may need to decide is what to do when show is
> >> given a tag object. Personally I think the current behaviour of
> >> dereferencing it to commit is fine (people who want to see the
> >> tag can always do 'git-verify-tag -v').
> >
> > How about adding the command line option "--tag" to git-show, which makes
> > it only show that tag. I'd also vote for a "--verbose|-v" flag to show the
> > contents of the tag _before_ showing the referenced object.
>
> Sounds sensible. Please make it so.
Actually, I rethought it. A tag _without_ what it tags makes no sense. See
my upcoming patch. And git-show really is as Porcelain as it gets, so it
should Do What I Mean.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 23:31 ` Junio C Hamano
2006-12-13 23:52 ` Peter Baumann
2006-12-14 0:16 ` Johannes Schindelin
@ 2006-12-14 8:28 ` Andreas Ericsson
2006-12-15 14:39 ` Jakub Narebski
2006-12-14 9:59 ` Andy Parkins
2006-12-14 23:52 ` Horst H. von Brand
4 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-14 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
>> * git-add has no output, whether it works or not
>
> "git add no-such-file" complains, and I think that is adequate.
> Now with Nico's 'add means adding contents, not path' change is
> in, we _might_ want to differentiate adding a path that was
> untracked before and updating the contents, but I think this
> again falls into "doing exactly as told" category.
>
Well, it should really let the user know if it fails. I for one would
like to know that. I wasn't aware of the fact that it was silent even in
those situations (perhaps because I've never run across it).
The errors that need to be reported are, afaics:
Content in 'path/to/file' is ignored according to path/to/.gitignore.
System error X happened while attempting Y.
Hash collisions.
Hash collisions wouldn't be too bad to check for in git add, because it
only has to compare a single object, although I agree that it probably
isn't necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 8:28 ` Andreas Ericsson
@ 2006-12-15 14:39 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 14:39 UTC (permalink / raw)
To: git
Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Andy Parkins <andyparkins@gmail.com> writes:
>>
>>> * git-add has no output, whether it works or not
>>
>> "git add no-such-file" complains, and I think that is adequate.
>> Now with Nico's 'add means adding contents, not path' change is
>> in, we _might_ want to differentiate adding a path that was
>> untracked before and updating the contents, but I think this
>> again falls into "doing exactly as told" category.
>>
>
> Well, it should really let the user know if it fails. I for one would
> like to know that. I wasn't aware of the fact that it was silent even in
> those situations (perhaps because I've never run across it).
>
> The errors that need to be reported are, afaics:
> Content in 'path/to/file' is ignored according to path/to/.gitignore.
This is not an error, just a warning. Sometimes user want's to add a file
which is otherwise ignored (e.g. due to glob), sometimes user adds ignored
file by mistake.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 23:31 ` Junio C Hamano
` (2 preceding siblings ...)
2006-12-14 8:28 ` Andreas Ericsson
@ 2006-12-14 9:59 ` Andy Parkins
2006-12-14 10:21 ` Junio C Hamano
2006-12-14 21:22 ` What's in git.git (stable) Junio C Hamano
2006-12-14 23:52 ` Horst H. von Brand
4 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 9:59 UTC (permalink / raw)
To: git
On Wednesday 2006 December 13 23:31, Junio C Hamano wrote:
> I am moderately against making a command verbosely report when
I'm not sure "verbose" is the word for one extra line of output:
$ git commit
Revision XXXXXXXXXXXXXXXXXX successfully added.
I'd actually argue that git-commit is a particular problem because it's too
fast. You quit editing your commit message and bang, you're back at the
command line. Then you run git-log to make sure it really was committed.
> it did exactly what it was told to do, _unless_ the command is
> expected to take longer than other commands in git suite, or it
> is something the user rarely runs.
In the specific case of commit I really think the hash that was added needs to
be printed. I often do a series of git-commits on separate files; to find
out the hash of one of those recent commits I then hop over to qgit to look.
If it were right there on my terminal I wouldn't need to have qgit open all
the time.
> > * git-branch is not verbose enough when creating a new
> The same comment applies here.
Right back at you. "what it was told to do", is not a clear cut thing. Bear
in mind that users make mistakes (I certainly do), so what I told it to do
was not necessarily what I wanted it to do. With no output to tell me what
actually happened, it makes it harder to go back and see what you did wrong.
> However, perhaps you could make lack of "[user] expert = true"
> in ~/.gitconfig to trigger more verbose messages that say "yes
> sir I did what I was told to do".
I've always thought that programs that needed an expert/beginner split were
badly designed.
I'm not sure you're characterising the messages correctly with "yes
sir I did what I was told to do". That sort of output would truly be useless.
However, going back to my git-commit example, I didn't say "commit and give
this the hash XXXXXXXX", I said "commit". git makes up the hash for me, and
so should really tell me that hash.
> Not interested in implementing that myself at all, though.
I've gotten a far more positive response than I'd expected, so it doesn't
surprise me.
> > Tell them if they
> > made a branch as well, which branch they are now on.
>
> I think you are talking about "checkout -b" not commit here;
> this might be a borderline (branch creation is less often done
> and it might warrant assuring feedback), but I think it still
> falls into the "doing exactly what it was told to do" category.
You're right, I was. The reason I think feedback is useful is because of the
two ways of making a new branch:
- git-branch XYZ
This makes a new branch but DOESN'T leave me on XYZ
- git-commit -b XYZ
This makes a new branch and switches to XYZ
I can't tell you the number of times I get this wrong. It's not because I
don't know if I stop to think, it's because I'm thinking about the project,
not the VCS.
> No. It either says patch is corrupt, or a hunk at this line
> does not apply. I do not see what more would you would want to
> ask it to say.
I've been building a repository that contains every kernel release since
v1.0.0; I did it by downloading every patch and "git-apply"ing them one at a
time. Along the way, I had a few occasions where the patch didn't apply. I
would get the "hunk didn't apply" message. (e.g. v1.1/patch54.bz2 if you're
interested)
Now - it /should/ apply, this is a published patch; I investigated each one,
and it was always down to a whitespace problem. The current version didn't
have the same whitespace as the patch was expecting; often part of a much
larger patch which mostly applied. git-apply could have told me...
While applying hunk #17, the following update would not apply to the file
this/that/theother.c
-#endif
+#endif
Instead I had to git-checkout HEAD; bzcat patch | git-apply --reject;
find . -name "*.rej"; vim; git update-index; blah, blah blah.
> As long as your solution does not accidentally lose local,
> unrelated changes, changing "git-rebase --skip" to do the needed
> clean-up itself for the user would be Ok (I think we would want
Of course; never discarding data always takes precedence.
> While I agree the users need to be taught about 'prune', I do
> think immediately after running the above commands is exactly
> the wrong point to run 'prune'. 'prune' should not be run while
> you are busily munging the tip of the branch with rebase and
> reset to come up with something that you can call "oh, I am done
> with this series for now." Otherwise even lost-found would not
> be able to help you.
Absolutely; I wasn't suggesting that the message should say "now run
git-prune"; otherwise we might as well run git-prune ourselves. I don't
really know that the solution is; but I do think we need one.
> In general the principle ought to be not to say anything if the
> command does exactly what it was told to do successfully, unless
> the operation is expected to take longer than other normal
> commands in the git suite, or something that is rarely used.
git is its own worst enemy here I think. I still have doubts that something
actually happened when I run commands because they return so quickly.
> Perhaps under "[user] expert" control.
I think the problem with that is going to be that there will be disagreement
about which commands should output what in which mode. "I like git-commit to
tell me what it committed, but don't want git-add to list files" sorts of
thing.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 9:59 ` Andy Parkins
@ 2006-12-14 10:21 ` Junio C Hamano
2006-12-14 11:36 ` Andy Parkins
2006-12-15 4:07 ` Nicolas Pitre
2006-12-14 21:22 ` What's in git.git (stable) Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 10:21 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> $ git commit
> Revision XXXXXXXXXXXXXXXXXX successfully added.
>
> I'd actually argue that git-commit is a particular problem because it's too
> fast. You quit editing your commit message and bang, you're back at the
> command line. Then you run git-log to make sure it really was committed.
You keep repeating that you want to know the object name of the
newly created commit. I would very strongly agree with you that
it would be a fatal UI bug of git-commit if that information
were vital for the end user after making each commit.
But you never communicate with your own git repository using the
SHA-1 object names when talking about commits you made recently
(you would have the SHA-1 output from your updated version of
'git commit' command on the screen or in your scrollbuffer for
them -- you would need to refer to commits older than what your
scrollbuffer has in different way anyway). Git gives branch~<n>
notation, and commands like "git log --pretty=short" and friends
would show them which you can easily cut&paste. When people
talk about object names on the mailing list, they do so by
asking "git log" and friends to find them out -- it is pretty
much "on demand" type of thing and I do not think continually
mentioning SHA-1 object names buys us anything.
In other words, the following transcript would be possible but
not realistic:
$ git commit
Revision deadbeef0000 created.
: now what did I do?
$ git show deadbeef0000
: oops, that is wrong
$ git reset --hard deadbeef0000^
So I do not think "git commit" is a valid example. I also agree
with Shawn that "git add" that says 6781 files were added is
pointless.
>> However, perhaps you could make lack of "[user] expert = true"
>> in ~/.gitconfig to trigger more verbose messages that say "yes
>> sir I did what I was told to do".
>
> I've always thought that programs that needed an expert/beginner split were
> badly designed.
There probably is a truth in that. Let's not add verbosity
unnecessarily.
I agree with you that making some commands with progress
indication less chatty would be a good clean-up.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:21 ` Junio C Hamano
@ 2006-12-14 11:36 ` Andy Parkins
2006-12-14 11:45 ` Shawn Pearce
2006-12-15 15:26 ` Jakub Narebski
2006-12-15 4:07 ` Nicolas Pitre
1 sibling, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 11:36 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 10:21, Junio C Hamano wrote:
> You keep repeating that you want to know the object name of the
Oh dear, you're right; I am terribly repetative. Sorry.
Oh dear, you're right; I am terribly repetative. Sorry.
;-)
> But you never communicate with your own git repository using the
> SHA-1 object names when talking about commits you made recently
How's this then:
$ git commit
$ git commit
$ git commit
$ git reset HEAD^^^
"AGGGHHHHHH! I meant HEAD^^"
At this point I start running "git-prune -n | grep commit" and some liberal
use of git-show to try and find the hash of the object so I can do
$ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED
> So I do not think "git commit" is a valid example. I also agree
> with Shawn that "git add" that says 6781 files were added is
> pointless.
Okay.
> > I've always thought that programs that needed an expert/beginner split
> > were badly designed.
>
> There probably is a truth in that. Let's not add verbosity
> unnecessarily.
My habit is always to be overly verbose in program output; however, I realise
that not everybody likes that. None of these things cause me any difficulty
in my use of git. However, my Dad also is an engineer, but he's not so
comfortable with VCS; for him almost every part of git is a mystery.
Commands that run and don't say anything are confusing because he didn't
really know what they were /meant/ to do; he's just got a set of recipes that
he knows to type. He's probably an extreme case, and not a good model for
typical user - on the other hand, I would say that if he can use it, then it
is officially newbie-friendly. :-)
> I agree with you that making some commands with progress
> indication less chatty would be a good clean-up.
These are actually the ones I feel more strongly about. Too much output just
drowns out the information that people really need.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:36 ` Andy Parkins
@ 2006-12-14 11:45 ` Shawn Pearce
2006-12-14 11:58 ` Carl Worth
` (2 more replies)
2006-12-15 15:26 ` Jakub Narebski
1 sibling, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 11:45 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> wrote:
> How's this then:
>
> $ git commit
> $ git commit
> $ git commit
> $ git reset HEAD^^^
>
> "AGGGHHHHHH! I meant HEAD^^"
>
> At this point I start running "git-prune -n | grep commit" and some liberal
> use of git-show to try and find the hash of the object so I can do
At this point I usually try to politely suggest that users do:
git repo-config --global core.logAllRefUpdates true
and in the future do something like:
> $ git commit # {4}
> $ git commit # {3}
> $ git commit # {2}
> $ git reset HEAD^^^ # {1}
>
> "AGGGHHHHHH! I meant HEAD^^"
$ git reset HEAD@{4}
should give you what
$ git reset HEAD^^
would have given had you not added the extra ^. :-)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:45 ` Shawn Pearce
@ 2006-12-14 11:58 ` Carl Worth
2006-12-14 12:05 ` Shawn Pearce
2006-12-14 17:47 ` What's in git.git (stable) Nicolas Pitre
2006-12-14 21:58 ` Junio C Hamano
2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-12-14 11:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Parkins, git
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Thu, 14 Dec 2006 06:45:46 -0500, Shawn Pearce wrote:
> At this point I usually try to politely suggest that users do:
>
> git repo-config --global core.logAllRefUpdates true
>
> and in the future do something like:
This when-you-first-learn-you-want-them-it's-too-late-to-get-them
aspect of ref logs is really annoying. It sets up an unkind trap for
users.
I know several people have suggested they be enabled by
default. What's the status of that suggestion? Rejected? Just
awaiting a patch?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:58 ` Carl Worth
@ 2006-12-14 12:05 ` Shawn Pearce
2006-12-14 14:03 ` reflog by default?, was " Johannes Schindelin
2006-12-14 18:06 ` Nicolas Pitre
0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 12:05 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Parkins, git
Carl Worth <cworth@cworth.org> wrote:
> This when-you-first-learn-you-want-them-it's-too-late-to-get-them
> aspect of ref logs is really annoying. It sets up an unkind trap for
> users.
Yes. Which is why its in my ~/.gitconfig. :-(
> I know several people have suggested they be enabled by
> default. What's the status of that suggestion? Rejected? Just
> awaiting a patch?
Its been suggested and discussed.
But the problem raised is that there are many types of repositories,
and not all should always have reflogs enabled, and its hard to
tell which one should and which shouldn't by default, and its even
worse to force it into a user's ~/.gitconfig as then repositories
which should not have reflogs are getting them anyway.
* Normal working repository (wants reflogs);
* Bare private (backup) repository (wants reflogs);
* Bare shared repository (probably doesn't want reflogs);
* Import generated repository (probably doesn't want reflogs);
...
Find a way to make git-init-db know the difference magically and
you'll probably see a patch emerge quickly afterwards. But right
now I don't think anyone really has a great solution to the problem.
I know Junio wrote something on this not too long ago (and it was a
good writeup too) but I can never find threads in gmane's archives,
so I'm just going to leave that to someone else...
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* reflog by default?, was Re: What's in git.git (stable)
2006-12-14 12:05 ` Shawn Pearce
@ 2006-12-14 14:03 ` Johannes Schindelin
2006-12-14 18:06 ` Nicolas Pitre
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 14:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, Andy Parkins, git
Hi,
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> * Normal working repository (wants reflogs);
> * Bare private (backup) repository (wants reflogs);
> * Bare shared repository (probably doesn't want reflogs);
> * Import generated repository (probably doesn't want reflogs);
In contrast, I think that reflogs make lots of sense for shared repos,
and less sense for bare (non-shared) ones...
So, I'd say: enable reflog by default, unless it is bare _and_ not shared.
But then, cmd_init_db() no longer knows if it was called with "--bare" or
not.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 12:05 ` Shawn Pearce
2006-12-14 14:03 ` reflog by default?, was " Johannes Schindelin
@ 2006-12-14 18:06 ` Nicolas Pitre
2006-12-14 19:52 ` Junio C Hamano
2006-12-14 19:58 ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
1 sibling, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 18:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, Andy Parkins, git
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> But the problem raised is that there are many types of repositories,
> and not all should always have reflogs enabled, and its hard to
> tell which one should and which shouldn't by default, and its even
> worse to force it into a user's ~/.gitconfig as then repositories
> which should not have reflogs are getting them anyway.
Thank you for reminding me the reasons why.
However I'd argue that the lack of reflog data is much much worse than
needlessly having it.
It is therefore much saner to disable it in the config and remove the
unwanted reflog files than being sorry because it wasn't enabled when
you would have needed it.
> * Normal working repository (wants reflogs);
> * Bare private (backup) repository (wants reflogs);
> * Bare shared repository (probably doesn't want reflogs);
> * Import generated repository (probably doesn't want reflogs);
And what would be the actual problem if reflog was enabled (i.e. was not
explicitly disabled if enabled by default) in those last two cases?
> Find a way to make git-init-db know the difference magically and
> you'll probably see a patch emerge quickly afterwards. But right now
> I don't think anyone really has a great solution to the problem.
I'd say screw that. The solution should really be this patch:
diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c
@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
int trust_executable_bit = 1;
int assume_unchanged;
int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
int warn_ambiguous_refs = 1;
int repository_format_version;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> I know Junio wrote something on this not too long ago (and it was a
> good writeup too) but I can never find threads in gmane's archives,
> so I'm just going to leave that to someone else...
Well I must have missed it.
But unless there is real harm to have reflog enabled even when you don't
need it I really think the default should be set to enabled.
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 18:06 ` Nicolas Pitre
@ 2006-12-14 19:52 ` Junio C Hamano
2006-12-14 20:02 ` Shawn Pearce
2006-12-14 20:17 ` Nicolas Pitre
2006-12-14 19:58 ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 19:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Shawn Pearce
Nicolas Pitre <nico@cam.org> writes:
> I'd say screw that. The solution should really be this patch:
>
> diff --git a/environment.c b/environment.c
> index 84d870c..98275b2 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> int trust_executable_bit = 1;
> int assume_unchanged;
> int prefer_symlink_refs;
> -int log_all_ref_updates;
> +int log_all_ref_updates = 1;
> int warn_ambiguous_refs = 1;
> int repository_format_version;
> char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
>
That changes what the command does to existing repositories,
which is somewhat impolite.
I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 19:52 ` Junio C Hamano
@ 2006-12-14 20:02 ` Shawn Pearce
2006-12-14 20:22 ` Nicolas Pitre
` (2 more replies)
2006-12-14 20:17 ` Nicolas Pitre
1 sibling, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I'd say screw that. The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> > int trust_executable_bit = 1;
> > int assume_unchanged;
> > int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> > int warn_ambiguous_refs = 1;
> > int repository_format_version;
> > char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
>
> That changes what the command does to existing repositories,
> which is somewhat impolite.
Yes, but users are forgetting to enable them. They will work in
a new repository having that feature, move to an older one and not
have it, but expect it to be there.
As I recall the primary objection to enabling them by default
when I first introduced them was that core.logAllRefUpdates=true
meant that refs/tags/<name> were also being logged. This was not a
great idea as tags generally did not change once they were created.
You fixed that and now it just makes sense to enable it for branch
heads all of the time.
> I am not opposed too much to an updated version of the tool that
> sets the configuration on by default for newly created
> repositories, though.
I almost did that in my patch - but decided against it for the
reason I just noted above.
Does anyone on the mailing list really have an objection to having
reflogs on by default?
About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 20:02 ` Shawn Pearce
@ 2006-12-14 20:22 ` Nicolas Pitre
2006-12-14 20:35 ` Junio C Hamano
2006-12-14 21:55 ` Andreas Ericsson
2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 20:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > That changes what the command does to existing repositories,
> > which is somewhat impolite.
>
> Yes, but users are forgetting to enable them. They will work in
> a new repository having that feature, move to an older one and not
> have it, but expect it to be there.
I concur entirely.
> > I am not opposed too much to an updated version of the tool that
> > sets the configuration on by default for newly created
> > repositories, though.
>
> I almost did that in my patch - but decided against it for the
> reason I just noted above.
>
> Does anyone on the mailing list really have an objection to having
> reflogs on by default?
I certainly don't.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 20:02 ` Shawn Pearce
2006-12-14 20:22 ` Nicolas Pitre
@ 2006-12-14 20:35 ` Junio C Hamano
2006-12-14 22:41 ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
2006-12-14 22:44 ` What's in git.git (stable) Shawn Pearce
2006-12-14 21:55 ` Andreas Ericsson
2 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 20:35 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Does anyone on the mailing list really have an objection to having
> reflogs on by default?
When you talk about potential breakage for existing users, you
should not be asking people on THIS list. You instead should
talk with or at least think about people on linux-kernel, x.org
and wine people, and possibly others. git is maturing, and we
cannot expect that most of the users are paying attention to
what is happening on this list anymore.
I 100% agree that it makes sense to have reflog enabled for a
repository with an associated worktree. I would say that we do
not even need it to be conditional on the configuration variable
for such a repository.
My answer to your question is:
kernel.org:/pub/scm/
I would REALLY be worried to have reflog enabled at a public
distribution point where the only ways the owners interact with
it daily are 'git push' and 'git pull'. As you mentioned, there
is one extra potential receive-pack failure, and in general it
is one more thing that can go wrong, and hard to notice breakage
because it is on the other side of the connection.
Worse yet, there is no easy way to garbage collect. Even in an
end-user repository with a worktree, the only way to garbage
collect older reflog entries is to edit the reflog files to
remove the top part.
Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
then enable it and otherwise honor the configuration variable,
without changing the default in the code (with your patch) nor
in the default configuration ("enable for new repositories" as I
suggested) might be a workable compromise.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-14 20:35 ` Junio C Hamano
@ 2006-12-14 22:41 ` Shawn O. Pearce
2006-12-14 23:10 ` J. Bruce Fields
2006-12-15 0:13 ` Johannes Schindelin
2006-12-14 22:44 ` What's in git.git (stable) Shawn Pearce
1 sibling, 2 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2006-12-14 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/config.txt | 7 +++++--
builtin-init-db.c | 4 ++++
cache.h | 1 +
environment.c | 9 +++++++++
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..8abb082 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -79,8 +79,11 @@ core.logAllRefUpdates::
file is automatically created for branch heads.
This information can be used to determine what commit
- was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ was the tip of a branch "2 days ago".
+
+ This value is true by default in a repository that has
+ a working directory associated with it, and false by
+ default in a bare repository.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..214fc8e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -239,6 +239,10 @@ static void create_default_files(const char *git_dir, const char *template_path)
git_config_set("core.filemode",
filemode ? "true" : "false");
}
+
+ /* Enable logAllRefUpdates if a working tree is attached */
+ git_config_set("core.logallrefupdates",
+ !is_bare_git_dir(git_dir) ? "true" : "false");
}
static const char init_db_usage[] =
diff --git a/cache.h b/cache.h
index f2ec5c8..2d3df98 100644
--- a/cache.h
+++ b/cache.h
@@ -123,6 +123,7 @@ extern int cache_errno;
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
+extern int is_bare_git_dir(const char *dir);
extern const char *get_git_dir(void);
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
diff --git a/environment.c b/environment.c
index 84d870c..b7256eb 100644
--- a/environment.c
+++ b/environment.c
@@ -48,6 +48,15 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = xstrdup(git_path("info/grafts"));
+ log_all_ref_updates = !is_bare_git_dir(git_dir);
+}
+
+int is_bare_git_dir (const char *dir)
+{
+ if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
+ return 0;
+ const char *s = strrchr(dir, '/');
+ return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
}
const char *get_git_dir(void)
--
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-14 22:41 ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
@ 2006-12-14 23:10 ` J. Bruce Fields
2006-12-14 23:18 ` Shawn Pearce
2006-12-15 0:13 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: J. Bruce Fields @ 2006-12-14 23:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> New and experienced Git users alike are finding out too late that
> they forgot to enable reflogs in the current repository, and cannot
> use the information stored within it to recover from an incorrectly
> entered command such as `git reset --hard HEAD^^^` when they really
> meant HEAD^^ (aka HEAD~2).
Stupid question--I assume a mention in the reflog doesn't count as a
real reference to an object, so they won't save you in the case when you
pruned recently?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-14 23:10 ` J. Bruce Fields
@ 2006-12-14 23:18 ` Shawn Pearce
2006-12-14 23:42 ` J. Bruce Fields
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 23:18 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> > New and experienced Git users alike are finding out too late that
> > they forgot to enable reflogs in the current repository, and cannot
> > use the information stored within it to recover from an incorrectly
> > entered command such as `git reset --hard HEAD^^^` when they really
> > meant HEAD^^ (aka HEAD~2).
>
> Stupid question--I assume a mention in the reflog doesn't count as a
> real reference to an object, so they won't save you in the case when you
> pruned recently?
Not a stupid question. Your assumption is correct, its not a real
reference, so prune will remove things that the log mentions but
that refs don't currently mention.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-14 23:18 ` Shawn Pearce
@ 2006-12-14 23:42 ` J. Bruce Fields
0 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2006-12-14 23:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
On Thu, Dec 14, 2006 at 06:18:32PM -0500, Shawn Pearce wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > Stupid question--I assume a mention in the reflog doesn't count as a
> > real reference to an object, so they won't save you in the case when you
> > pruned recently?
>
> Not a stupid question. Your assumption is correct, its not a real
> reference, so prune will remove things that the log mentions but
> that refs don't currently mention.
OK, thanks. So we just need to make sure that's documented someplace.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-14 22:41 ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
2006-12-14 23:10 ` J. Bruce Fields
@ 2006-12-15 0:13 ` Johannes Schindelin
2006-12-15 0:20 ` Shawn Pearce
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 0:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
Hi,
On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> +int is_bare_git_dir (const char *dir)
> +{
> + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> + return 0;
> + const char *s = strrchr(dir, '/');
> + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
> }
This function does not really determine if the repo is bare. I have no
better name for it, though.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-15 0:13 ` Johannes Schindelin
@ 2006-12-15 0:20 ` Shawn Pearce
2006-12-15 21:55 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 0:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>
> > +int is_bare_git_dir (const char *dir)
> > +{
> > + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> > + return 0;
> > + const char *s = strrchr(dir, '/');
> > + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
> > }
>
> This function does not really determine if the repo is bare. I have no
> better name for it, though.
guess_if_bare_git_dir ?
I struggled to name that thing because it can't really tell, its just
guessing... but it is going to be right most of the time. Of course
I'm sure there's some Git user somewhere who will confuse it.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
2006-12-15 0:20 ` Shawn Pearce
@ 2006-12-15 21:55 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Johannes Schindelin
Shawn Pearce <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>>
>> > +int is_bare_git_dir (const char *dir)
>> > +{
>> > + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
>> > + return 0;
>> > + const char *s = strrchr(dir, '/');
>> > + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
>> > }
>>
>> This function does not really determine if the repo is bare. I have no
>> better name for it, though.
>
> guess_if_bare_git_dir ?
>
> I struggled to name that thing because it can't really tell, its just
> guessing... but it is going to be right most of the time. Of course
> I'm sure there's some Git user somewhere who will confuse it.
I think the name is fine, but probably a comment in front would
help unconfuse people.
/* Does it look like a repository without a working tree? */
Unfortunately there currently are public bare repositories that
have index under them because they were primed by rsync from
developers' working repositories. I do not think it is
unreasonable to persuade owners of them to drop index -- then we
could use absence of $GIT_DIR/index as a strong clue that the
repository is bare.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 20:35 ` Junio C Hamano
2006-12-14 22:41 ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
@ 2006-12-14 22:44 ` Shawn Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
> then enable it and otherwise honor the configuration variable,
> without changing the default in the code (with your patch) nor
> in the default configuration ("enable for new repositories" as I
> suggested) might be a workable compromise.
See my latest patch. Though that patch also sets the value in the
config file, much as core.filemode is also set in the config file,
based on the guess determined by init-db at the time it was executed.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 20:02 ` Shawn Pearce
2006-12-14 20:22 ` Nicolas Pitre
2006-12-14 20:35 ` Junio C Hamano
@ 2006-12-14 21:55 ` Andreas Ericsson
2006-12-15 21:55 ` Junio C Hamano
2 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-14 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Nicolas Pitre, git
Shawn Pearce wrote:
>
> About the only trouble that can cause is a failed push when
> git-receive-pack needs to generate the reflog entry but cannot
> get the user's committer data because their gecos information
> doesn't exist.
>
In that case, it would be best if it let the commit go through using
only the username. Reflogs are fixable afterwards, so there's no real
harm done.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 21:55 ` Andreas Ericsson
@ 2006-12-15 21:55 ` Junio C Hamano
2006-12-16 2:54 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
Andreas Ericsson <ae@op5.se> writes:
> Shawn Pearce wrote:
>>
>> About the only trouble that can cause is a failed push when
>> git-receive-pack needs to generate the reflog entry but cannot
>> get the user's committer data because their gecos information
>> doesn't exist.
>
> In that case, it would be best if it let the commit go through using
> only the username. Reflogs are fixable afterwards, so there's no real
> harm done.
This sounds sensible, regardless of the current discussion on
the default 'logallrefupdates' setting.
Volunteers?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 21:55 ` Junio C Hamano
@ 2006-12-16 2:54 ` Shawn Pearce
0 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-16 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
Junio C Hamano <junkio@cox.net> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Shawn Pearce wrote:
> >>
> >> About the only trouble that can cause is a failed push when
> >> git-receive-pack needs to generate the reflog entry but cannot
> >> get the user's committer data because their gecos information
> >> doesn't exist.
> >
> > In that case, it would be best if it let the commit go through using
> > only the username. Reflogs are fixable afterwards, so there's no real
> > harm done.
>
> This sounds sensible, regardless of the current discussion on
> the default 'logallrefupdates' setting.
>
> Volunteers?
Its a good idea. I'll do it later tonight, after dinner.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 19:52 ` Junio C Hamano
2006-12-14 20:02 ` Shawn Pearce
@ 2006-12-14 20:17 ` Nicolas Pitre
2006-12-14 20:50 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I'd say screw that. The solution should really be this patch:
> >
> > diff --git a/environment.c b/environment.c
> > index 84d870c..98275b2 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;
> > int trust_executable_bit = 1;
> > int assume_unchanged;
> > int prefer_symlink_refs;
> > -int log_all_ref_updates;
> > +int log_all_ref_updates = 1;
> > int warn_ambiguous_refs = 1;
> > int repository_format_version;
> > char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> >
>
> That changes what the command does to existing repositories,
> which is somewhat impolite.
You must be kidding, aren't you?
Just in case you really are serious, let's pretend that being impolite
for something that has the potential of saving people's arses is
certainly worth it, much more that the little inconvenience of having
log files mysteriously appear and make no harm otherwise.
> I am not opposed too much to an updated version of the tool that
> sets the configuration on by default for newly created
> repositories, though.
Hmmm....
Well it is just that I strongly believe users with existing repos have
no really valid reason to not have this feature enabled. But making it
on in a default config file at repo creation time is better than
nothing.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 20:17 ` Nicolas Pitre
@ 2006-12-14 20:50 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 20:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Shawn Pearce
Nicolas Pitre <nico@cam.org> writes:
>> That changes what the command does to existing repositories,
>> which is somewhat impolite.
>
> You must be kidding, aren't you?
I am dead serious. I do not have _any_ issue on existing
repositories with a working tree, but I care deeply about public
distribution points. See my other message.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] Enable reflogs by default in all repositories.
2006-12-14 18:06 ` Nicolas Pitre
2006-12-14 19:52 ` Junio C Hamano
@ 2006-12-14 19:58 ` Shawn O. Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2006-12-14 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Carl Worth, Andy Parkins
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/config.txt | 3 ++-
environment.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..e093bcd 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -80,7 +80,8 @@ core.logAllRefUpdates::
This information can be used to determine what commit
was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ true by default to activate automated creation of log
+ files for all branch heads.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c
@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
int trust_executable_bit = 1;
int assume_unchanged;
int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
int warn_ambiguous_refs = 1;
int repository_format_version;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
--
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:45 ` Shawn Pearce
2006-12-14 11:58 ` Carl Worth
@ 2006-12-14 17:47 ` Nicolas Pitre
2006-12-14 21:58 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:47 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Parkins, git
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Andy Parkins <andyparkins@gmail.com> wrote:
> > How's this then:
> >
> > $ git commit
> > $ git commit
> > $ git commit
> > $ git reset HEAD^^^
> >
> > "AGGGHHHHHH! I meant HEAD^^"
> >
> > At this point I start running "git-prune -n | grep commit" and some liberal
> > use of git-show to try and find the hash of the object so I can do
>
> At this point I usually try to politely suggest that users do:
>
> git repo-config --global core.logAllRefUpdates true
>
And this is where I politely say that this option should be true by
default for everybody.
I don't recall why it isn't so yet.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:45 ` Shawn Pearce
2006-12-14 11:58 ` Carl Worth
2006-12-14 17:47 ` What's in git.git (stable) Nicolas Pitre
@ 2006-12-14 21:58 ` Junio C Hamano
2006-12-14 22:50 ` Andy Parkins
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 21:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Andy Parkins
Shawn Pearce <spearce@spearce.org> writes:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> How's this then:
>>
>> $ git commit
>> $ git commit
>> $ git commit
>> $ git reset HEAD^^^
>>
>> "AGGGHHHHHH! I meant HEAD^^"
>>
>> At this point I start running "git-prune -n | grep commit" and some liberal
>> use of git-show to try and find the hash of the object so I can do
>
> At this point I usually try to politely suggest that users do:
>
> git repo-config --global core.logAllRefUpdates true
>
> and in the future do something like:
>
>> $ git commit # {4}
>> $ git commit # {3}
>> $ git commit # {2}
>> $ git reset HEAD^^^ # {1}
>>
>> "AGGGHHHHHH! I meant HEAD^^"
>
> $ git reset HEAD@{4}
>
> should give you what
>
> $ git reset HEAD^^
>
> would have given had you not added the extra ^. :-)
Correct but a bad example that does not demonstrate the real
power of reflog. Andy's AGGGHHHHHH can be recovered with a
simple:
$ git reset ORIG_HEAD
The real beauty of reflog is that you can usually count number
of commands (not just commit) the way you did and recover with
the @{n} syntax. With one caveat -- a porcelain might implement
what it does as more than one transaction on the ref, in which
case counting commands does not help. You need to first make
sure the value of n in @{n} you thought is appropriate is really
the one you want; you would always run "git show -s HEAD@{4}"
before doing the recovering reset in practice, in other words.
And it is not very easy to view where ref was in each step with
existing set of tools.
Not until the attached patch, which was very lightly tested.
You would use it like this:
$ git-show-branch --reflog next
! [next@{0}] Merge branch 'js/show' into next
! [next@{1}] Merge branch 'jc/cdup' into next
! [next@{2}] Merge branch 'master' into next
! [next@{3}] Merge branch 'jc/cdup' into next
----
- [next@{0}] Merge branch 'js/show' into next
+ [next@{0}^2] git-show: grok blobs, trees and tags, too
-- [next@{1}] Merge branch 'jc/cdup' into next
++ [next@{1}^2] git-reset [--mixed] <tree> [--] <paths>...
++ [next@{1}^2^] git-reset: make it work from within a subdirectory.
++ [next@{1}^2~2] git-fetch: make it work from within a subdirectory.
++ [next@{0}^2^] INSTALL: no need to have GNU diff installed
-- [next@{0}^2~2] Merge branch 'maint'
++ [next@{0}^2~2^2] Bypass expensive content comparsion during...
- [next@{3}] Merge branch 'jc/cdup' into next
+ [next@{3}^2] git-reset [--mixed] <tree> [--] <paths>...
+ [next@{3}^2^] git-reset: make it work from within a subdirectory.
+ [next@{3}^2~2] git-fetch: make it work from within a subdirectory.
+ [next@{3}^2~3] Bypass expensive content comparsion during re...
++ + [next@{0}^2~3] Update git-diff documentation
-- - [next@{0}^2~4] Merge branch 'jc/diff--cached'
++ + [next@{0}^2~5] git-svn: allow both diff.color and color.diff
++ + [next@{0}^2~6] repacked packs should be read-only
---- [next@{2}] Merge branch 'master' into next
This shows the actual reflog from the 'next' branch on my
primary repository. It shows that I did a merge of jc/cdup
branch into 'next' to run tests at next@{3}, but later rewound
that merge at next@{2} and merged the rebased jc/cdup again
later at next@{1} [*1*].
[Footnote]
*1* Of course, I did all of the above rewinding and rebasing
before pushing the result out, so the general public do not have
to worry about rewinding and rebasing.
---
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index fb1a400..559bb18 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -6,7 +6,7 @@
#include "builtin.h"
static const char show_branch_usage[] =
-"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
+"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...] | --reflog[=n] <branch>";
static int default_num;
static int default_alloc;
@@ -17,6 +17,8 @@ static const char **default_arg;
#define REV_SHIFT 2
#define MAX_REVS (FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */
+#define DEFAULT_REFLOG 4
+
static struct commit *interesting(struct commit_list *list)
{
while (list) {
@@ -570,6 +572,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
int head_at = -1;
int topics = 0;
int dense = 1;
+ int reflog = 0;
git_config(git_show_branch_config);
@@ -615,6 +618,15 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
dense = 0;
else if (!strcmp(arg, "--date-order"))
lifo = 0;
+ else if (!strcmp(arg, "--reflog")) {
+ reflog = DEFAULT_REFLOG;
+ }
+ else if (!strncmp(arg, "--reflog=", 9)) {
+ char *end;
+ reflog = strtoul(arg + 9, &end, 10);
+ if (*end != '\0')
+ die("unrecognized reflog count '%s'", arg + 9);
+ }
else
usage(show_branch_usage);
ac--; av++;
@@ -622,7 +634,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
ac--; av++;
/* Only one of these is allowed */
- if (1 < independent + merge_base + (extra != 0))
+ if (1 < independent + merge_base + (extra != 0) + (!!reflog))
usage(show_branch_usage);
/* If nothing is specified, show all branches by default */
@@ -631,9 +643,22 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
if (all_heads + all_tags)
snarf_refs(all_heads, all_tags);
- while (0 < ac) {
- append_one_rev(*av);
- ac--; av++;
+ if (reflog) {
+ int reflen;
+ if (!ac)
+ die("--reflog option needs one branch name");
+ reflen = strlen(*av);
+ for (i = 0; i < reflog; i++) {
+ char *name = xmalloc(reflen + 20);
+ sprintf(name, "%s@{%d}", *av, i);
+ append_one_rev(name);
+ }
+ }
+ else {
+ while (0 < ac) {
+ append_one_rev(*av);
+ ac--; av++;
+ }
}
head_p = resolve_ref("HEAD", head_sha1, 1, NULL);
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 21:58 ` Junio C Hamano
@ 2006-12-14 22:50 ` Andy Parkins
2006-12-15 15:38 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 22:50 UTC (permalink / raw)
To: git
On Thursday 2006, December 14 21:58, Junio C Hamano wrote:
> Correct but a bad example that does not demonstrate the real
> power of reflog. Andy's AGGGHHHHHH can be recovered with a
> simple:
>
> $ git reset ORIG_HEAD
HAHA! I knew reading this mailing list would pay off.
It amazes me that there is always an answer. It's almost becoming a
pantomime - I say "well git can't do this", and you say "oh yes it can".
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 22:50 ` Andy Parkins
@ 2006-12-15 15:38 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 15:38 UTC (permalink / raw)
To: git
Andy Parkins wrote:
> On Thursday 2006, December 14 21:58, Junio C Hamano wrote:
>
>> Correct but a bad example that does not demonstrate the real
>> power of reflog. Andy's AGGGHHHHHH can be recovered with a
>> simple:
>>
>> $ git reset ORIG_HEAD
>
> HAHA! I knew reading this mailing list would pay off.
>
> It amazes me that there is always an answer. It's almost becoming a
> pantomime - I say "well git can't do this", and you say "oh yes it can".
And it is mentioned in git-reset(1), although:
* it would be nice to have example with ORIG_HEAD about how
to recover from bad (wrong) git reset in EXAMPLES section.
* it would be nice to mention that the first example can
be now done with simply "edit; git commit -a --amend"
instead of "git reset --soft HEAD^; edit; git commit -a -c ORIG_HEAD"
(which can fail for merges).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:36 ` Andy Parkins
2006-12-14 11:45 ` Shawn Pearce
@ 2006-12-15 15:26 ` Jakub Narebski
2006-12-15 15:30 ` Nicolas Pitre
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 15:26 UTC (permalink / raw)
To: git
Andy Parkins wrote:
By the way, could you use slightly smaller number of columns? TIA.
> On Thursday 2006 December 14 10:21, Junio C Hamano wrote:
>> But you never communicate with your own git repository using the
>> SHA-1 object names when talking about commits you made recently
>
> How's this then:
>
> $ git commit
> $ git commit
> $ git commit
> $ git reset HEAD^^^
>
> "AGGGHHHHHH! I meant HEAD^^"
>
> At this point I start running "git-prune -n | grep commit" and some liberal
> use of git-show to try and find the hash of the object so I can do
>
> $ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED
That is what reflog is for. By the way, is core.logAllRefUpdates set
to "true" (or "heads") by default now?
Although I'm not against
$ git commit -v
Revision XXXXXXXXXXXXXXXXXX successfully added.
Notice -v/-verbose option.
>> So I do not think "git commit" is a valid example. I also agree
>> with Shawn that "git add" that says 6781 files were added is
>> pointless.
>
> Okay.
And git-add has -v option (although not --verbose).
>>> I've always thought that programs that needed an expert/beginner split
>>> were badly designed.
>>
>> There probably is a truth in that. Let's not add verbosity
>> unnecessarily.
>
> My habit is always to be overly verbose in program output; however, I realise
> that not everybody likes that. None of these things cause me any difficulty
> in my use of git. However, my Dad also is an engineer, but he's not so
> comfortable with VCS; for him almost every part of git is a mystery.
> Commands that run and don't say anything are confusing because he didn't
> really know what they were /meant/ to do; he's just got a set of recipes that
> he knows to type. He's probably an extreme case, and not a good model for
> typical user - on the other hand, I would say that if he can use it, then it
> is officially newbie-friendly. :-)
It would be nice to have some generic place in git config to specify
default options to git commands (at least for interactive shell). It
cannot be done using aliases. Perhaps defaults.<command> config variable?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 15:26 ` Jakub Narebski
@ 2006-12-15 15:30 ` Nicolas Pitre
2006-12-15 15:48 ` Andreas Ericsson
2006-12-15 23:22 ` Johannes Schindelin
0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 15:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Fri, 15 Dec 2006, Jakub Narebski wrote:
> It would be nice to have some generic place in git config to specify
> default options to git commands (at least for interactive shell). It
> cannot be done using aliases. Perhaps defaults.<command> config variable?
I would say the alias facility has to be fixed then.
In bash you can alias "ls" to "ls -l" and it just works.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 15:30 ` Nicolas Pitre
@ 2006-12-15 15:48 ` Andreas Ericsson
2006-12-15 16:08 ` Nicolas Pitre
2006-12-15 23:22 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
>> It would be nice to have some generic place in git config to specify
>> default options to git commands (at least for interactive shell). It
>> cannot be done using aliases. Perhaps defaults.<command> config variable?
>
> I would say the alias facility has to be fixed then.
>
> In bash you can alias "ls" to "ls -l" and it just works.
>
I think this is because git scripts that need a certain git command to
work a certain way don't want some alias to kick in and destroy things
for them. Shell-scripts would have the same problem if you alias "awk"
to "grep" f.e., which is why prudent shell-scripters use the "unalias
-a" thing.
Anyways, this should be largely solvable by inventing a "--no-aliases"
switch to the git wrapper, or by the scripts calling the programs they
need directly which, afaik, bypasses the alias logic. If it doesn't, it
should.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 15:48 ` Andreas Ericsson
@ 2006-12-15 16:08 ` Nicolas Pitre
2006-12-15 16:12 ` Shawn Pearce
2006-12-15 16:13 ` Andreas Ericsson
0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
On Fri, 15 Dec 2006, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> >
> > > It would be nice to have some generic place in git config to specify
> > > default options to git commands (at least for interactive shell). It
> > > cannot be done using aliases. Perhaps defaults.<command> config variable?
> >
> > I would say the alias facility has to be fixed then.
> >
> > In bash you can alias "ls" to "ls -l" and it just works.
> >
>
> I think this is because git scripts that need a certain git command to work a
> certain way don't want some alias to kick in and destroy things for them.
> Shell-scripts would have the same problem if you alias "awk" to "grep" f.e.,
> which is why prudent shell-scripters use the "unalias -a" thing.
Wouldn't it be possible for aliases to be effective only when issued
from an interactive shell? It is certainly true that aliases just make
no sense in a script.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 16:08 ` Nicolas Pitre
@ 2006-12-15 16:12 ` Shawn Pearce
2006-12-15 16:13 ` Andreas Ericsson
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 16:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andreas Ericsson, Jakub Narebski, git
Nicolas Pitre <nico@cam.org> wrote:
> Wouldn't it be possible for aliases to be effective only when issued
> from an interactive shell? It is certainly true that aliases just make
> no sense in a script.
Probably, but on Cygwin gitk needs to use 'git foo' to invoke a
command, even if 'git-foo' exists, because 'git-foo' might be a shell
script and the Cygwin wish process cannot execute shell scripts.
Worse it cannot pass down environment variables to git commands.
So it may be a little hard to tell in the git wrapper we are being
run from within gitk (or git-gui)...
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 16:08 ` Nicolas Pitre
2006-12-15 16:12 ` Shawn Pearce
@ 2006-12-15 16:13 ` Andreas Ericsson
1 sibling, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 16:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Andreas Ericsson wrote:
>
>> Nicolas Pitre wrote:
>>> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>>>
>>>> It would be nice to have some generic place in git config to specify
>>>> default options to git commands (at least for interactive shell). It
>>>> cannot be done using aliases. Perhaps defaults.<command> config variable?
>>> I would say the alias facility has to be fixed then.
>>>
>>> In bash you can alias "ls" to "ls -l" and it just works.
>>>
>> I think this is because git scripts that need a certain git command to work a
>> certain way don't want some alias to kick in and destroy things for them.
>> Shell-scripts would have the same problem if you alias "awk" to "grep" f.e.,
>> which is why prudent shell-scripters use the "unalias -a" thing.
>
> Wouldn't it be possible for aliases to be effective only when issued
> from an interactive shell? It is certainly true that aliases just make
> no sense in a script.
>
Yes, but then aliases wouldn't work in one-liners, which would be a bit
of a shame and pretty likely to cause some "interesting" bugreports.
Perhaps an environment variable GIT_IGNORE_ALIAS=yes that git-scripts
can set at the beginning of execution?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 15:30 ` Nicolas Pitre
2006-12-15 15:48 ` Andreas Ericsson
@ 2006-12-15 23:22 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 23:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
Hi,
On Fri, 15 Dec 2006, Nicolas Pitre wrote:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
> > It would be nice to have some generic place in git config to specify
> > default options to git commands (at least for interactive shell). It
> > cannot be done using aliases. Perhaps defaults.<command> config variable?
>
> I would say the alias facility has to be fixed then.
>
> In bash you can alias "ls" to "ls -l" and it just works.
So, why not use bash aliases?
Frankly, what git aliases try to achieve is a little bit different from
bash aliases. Bash knows exactly when a command is interactive, and has a
clear advantage there. Git _cannot_ know.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:21 ` Junio C Hamano
2006-12-14 11:36 ` Andy Parkins
@ 2006-12-15 4:07 ` Nicolas Pitre
2006-12-15 4:15 ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > $ git commit
> > Revision XXXXXXXXXXXXXXXXXX successfully added.
> >
> > I'd actually argue that git-commit is a particular problem because it's too
> > fast. You quit editing your commit message and bang, you're back at the
> > command line. Then you run git-log to make sure it really was committed.
>
> You keep repeating that you want to know the object name of the
> newly created commit. I would very strongly agree with you that
> it would be a fatal UI bug of git-commit if that information
> were vital for the end user after making each commit.
I think this is not the point.
Of course the name of the newly created commit isn't _that_ important.
But so is the "Committing initial tree 5220388..." message.
And in the commit case, you are left with a blank screen and just a
shell prompt after you quit the text editor for the log message, which
is a bit worrisome. My initial reflex is not to think "ah it just did
what I asked it" but rather "hmmm has it just crashed on me?"
Having a single line of feedback when a commit has completed would not
be overly verbose and remove that impression of committing into a
void I'd think.
Note that, as I said in another thread, I'm really not advocating for
git-add to do the same. The git-add is a relatively simple and
lightweight operation that has not the same impact as a commit has
_conceptually_. It doesn't clear the screen for one thing so just
returning to the shell prompt (unless -v is used) is plenty sufficient.
I'm following up with a patch to implement what I think should be done.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] make commit message a little more consistent and conforting
2006-12-15 4:07 ` Nicolas Pitre
@ 2006-12-15 4:15 ` Nicolas Pitre
2006-12-15 4:24 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
It is nicer to let the user know when a commit succeeded all the time,
not only the first time. Also the commit sha1 is much more useful than
the tree sha1 in this case.
This patch also introduces a -q switch to supress this message as well
as the summary of created/deleted files.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..1c31159 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -336,17 +336,9 @@ $ commit=$(echo 'Initial commit' | git-commit-tree $tree)
$ git-update-ref HEAD $commit
------------------------------------------------
-which will say:
-
-----------------
-Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
-----------------
-
-just to warn you about the fact that it created a totally new commit
-that is not related to anything else. Normally you do this only *once*
-for a project ever, and all later commits will be parented on top of an
-earlier commit, and you'll never see this "Committing initial tree"
-message ever again.
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
Again, normally you'd never actually do this by hand. There is a
helpful script called `git commit` that will do all of this for you. So
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 97d66ef..0b74cd7 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -113,6 +113,9 @@ but can be used to amend a merge commit.
as well. This is usually not what you want unless you
are concluding a conflicted merge.
+-q|--quiet::
+ Supress commit summary message.
+
\--::
Do not interpret any more arguments as options.
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..8606381 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -22,14 +22,14 @@ defaulting to local storage area
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
-Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
+Created commit c4d59f390b9cfd4318117afde11d601c1085f241
------------------------------------------------
-What are the 40 digits of hex that git responded to the first commit
-with?
+What are the 40 digits of hex that git responded to the commit with?
We saw in part one of the tutorial that commits have names like this.
It turns out that every object in the git history is stored under
@@ -39,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1
name), and that the contents of a git object will never change (since
that would change the object's name as well).
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
We can ask git about this particular object with the cat-file
-command--just cut-and-paste from the reply to the initial commit, to
-save yourself typing all 40 hex digits:
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
------------------------------------------------
-$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
-tree
+$ git-cat-file -t 54196cc2
+commit
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
------------------------------------------------
A tree can refer to one or more "blob" objects, each corresponding to
@@ -102,8 +114,7 @@ $ find .git/objects/
and the contents of these files is just the compressed data plus a
header identifying their length and their type. The type is either a
-blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
-so next we should look at a commit.
+blob, a tree, a commit, or a tag.
The simplest commit to find is the HEAD commit, which we can find
from .git/HEAD:
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index e2e690a..856f3cd 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -107,8 +107,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
if (new_parent(parents))
parents++;
}
- if (!parents)
- fprintf(stderr, "Committing initial tree %s\n", argv[1]);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
diff --git a/git-commit.sh b/git-commit.sh
index 05828bb..395bcd2 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -80,6 +80,7 @@ no_edit=
log_given=
log_message=
verify=t
+quiet=
verbose=
signoff=
force_author=
@@ -241,6 +242,10 @@ $1"
signoff=t
shift
;;
+ -q|--q|--qu|--qui|--quie|--quiet)
+ quiet=t
+ shift
+ ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t
shift
@@ -615,11 +620,17 @@ then
git-rerere
fi
-if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
+if test "$ret" = 0
then
- "$GIT_DIR"/hooks/post-commit
+ if test -x "$GIT_DIR"/hooks/post-commit
+ then
+ "$GIT_DIR"/hooks/post-commit
+ fi
+ if test -z "$quiet"
+ then
+ echo "Created${initial_commit:+ initial} commit $commit"
+ git-diff-tree --summary --root --no-commit-id HEAD
+ fi
fi
-test "$ret" = 0 && git-diff-tree --summary --root --no-commit-id HEAD
-
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 4:15 ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
@ 2006-12-15 4:24 ` Shawn Pearce
2006-12-15 8:34 ` Andreas Ericsson
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 4:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Andy Parkins, git
Nicolas Pitre <nico@cam.org> wrote:
> It is nicer to let the user know when a commit succeeded all the time,
> not only the first time. Also the commit sha1 is much more useful than
> the tree sha1 in this case.
I agree the commit sha1 is more useful than the tree sha1, but I'm
not really sure its useful to show the commit sha1 post commit.
If you want to show something the diffstat like what git merge does
is better.
For one thing it confirms that git accepted the changes. For another
it shows you *which* changes it accepted. Plus it responds just
like git-merge or git-pull does.
Of course the meaning of the diffstat is entirely different in both
cases; in the commit case its what has been recorded while in the
merge case its not only what has been recorded into your current
branch history but also what has been done to your working directory.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 4:24 ` Shawn Pearce
@ 2006-12-15 8:34 ` Andreas Ericsson
2006-12-15 15:09 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 8:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> It is nicer to let the user know when a commit succeeded all the time,
>> not only the first time. Also the commit sha1 is much more useful than
>> the tree sha1 in this case.
>
> I agree the commit sha1 is more useful than the tree sha1, but I'm
> not really sure its useful to show the commit sha1 post commit.
> If you want to show something the diffstat like what git merge does
> is better.
>
diffstats can be huge though. I'd rather have those only with -v option.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 8:34 ` Andreas Ericsson
@ 2006-12-15 15:09 ` Shawn Pearce
2006-12-15 15:32 ` Andreas Ericsson
2006-12-15 16:01 ` Nicolas Pitre
0 siblings, 2 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 15:09 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >Nicolas Pitre <nico@cam.org> wrote:
> >>It is nicer to let the user know when a commit succeeded all the time,
> >>not only the first time. Also the commit sha1 is much more useful than
> >>the tree sha1 in this case.
> >
> >I agree the commit sha1 is more useful than the tree sha1, but I'm
> >not really sure its useful to show the commit sha1 post commit.
> >If you want to show something the diffstat like what git merge does
> >is better.
> >
>
> diffstats can be huge though. I'd rather have those only with -v option.
But they are on by default for pull/merge, and disabled by -n.
They are on to tell you what you just got during the pull/merge.
If we want commit to confirm it did something successfully, I think
having it confirm what it committed by way of diffstat makes a lot
of sense.
Unfortunately -n is taken to mean --no-verify by git-commit, so
we probably cannot repurpose it to mean --no-summary, like it is
for merge/pull.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:09 ` Shawn Pearce
@ 2006-12-15 15:32 ` Andreas Ericsson
2006-12-15 15:40 ` Shawn Pearce
2006-12-15 16:01 ` Nicolas Pitre
1 sibling, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn Pearce wrote:
>>> Nicolas Pitre <nico@cam.org> wrote:
>>>> It is nicer to let the user know when a commit succeeded all the time,
>>>> not only the first time. Also the commit sha1 is much more useful than
>>>> the tree sha1 in this case.
>>> I agree the commit sha1 is more useful than the tree sha1, but I'm
>>> not really sure its useful to show the commit sha1 post commit.
>>> If you want to show something the diffstat like what git merge does
>>> is better.
>>>
>> diffstats can be huge though. I'd rather have those only with -v option.
>
> But they are on by default for pull/merge, and disabled by -n.
>
Yes, but it makes sense for merges where you generally pull someone
elses work or one of your topic branches because it gives a general feel
for the amount of modifications and are a sort of conclusion. Commits
are a different thing, because you should know what kind of changes
you've just done. If you don't you have other problems. I for one run
git diff quite frequently when I'm getting close to a commit to make
sure I don't get only the changes I want. I imagine others do too, so
getting a diffstat when issuing the actual commit would just be noisy
and irritating.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:32 ` Andreas Ericsson
@ 2006-12-15 15:40 ` Shawn Pearce
2006-12-15 15:50 ` Andreas Ericsson
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 15:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
Andreas Ericsson <ae@op5.se> wrote:
> Yes, but it makes sense for merges where you generally pull someone
> elses work or one of your topic branches because it gives a general feel
> for the amount of modifications and are a sort of conclusion. Commits
> are a different thing, because you should know what kind of changes
> you've just done. If you don't you have other problems. I for one run
> git diff quite frequently when I'm getting close to a commit to make
> sure I don't get only the changes I want. I imagine others do too, so
> getting a diffstat when issuing the actual commit would just be noisy
> and irritating.
I do the same (diff a lot before commit) and thus find commit
outputting anything at all to be noisy and irritating. Frankly
the new
git-diff-tree --summary --root --no-commit-id HEAD
that Junio put on the end is already irritating.
But it was added to help users verify that commit did what they
thought it would (see 61f5cb7f). By the same token sometimes users
accidentally commit files they didn't mean to, or forget to include
files they meant to include. Showing a diffstat would also be a
final sanity check for them.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:40 ` Shawn Pearce
@ 2006-12-15 15:50 ` Andreas Ericsson
2006-12-15 16:06 ` Nicolas Pitre
2006-12-15 18:21 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-12-15 15:50 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Yes, but it makes sense for merges where you generally pull someone
>> elses work or one of your topic branches because it gives a general feel
>> for the amount of modifications and are a sort of conclusion. Commits
>> are a different thing, because you should know what kind of changes
>> you've just done. If you don't you have other problems. I for one run
>> git diff quite frequently when I'm getting close to a commit to make
>> sure I don't get only the changes I want. I imagine others do too, so
>> getting a diffstat when issuing the actual commit would just be noisy
>> and irritating.
>
> I do the same (diff a lot before commit) and thus find commit
> outputting anything at all to be noisy and irritating. Frankly
> the new
>
I could live with one line (Committed revision %d), but a diffstat is
always 3 lines minimum, which might well turn out to be 2 lines more
than I changed. That's way too noisy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:40 ` Shawn Pearce
2006-12-15 15:50 ` Andreas Ericsson
@ 2006-12-15 16:06 ` Nicolas Pitre
2006-12-15 18:21 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
On Fri, 15 Dec 2006, Shawn Pearce wrote:
> I do the same (diff a lot before commit) and thus find commit
> outputting anything at all to be noisy and irritating. Frankly
> the new
>
> git-diff-tree --summary --root --no-commit-id HEAD
>
> that Junio put on the end is already irritating.
>
> But it was added to help users verify that commit did what they
> thought it would (see 61f5cb7f). By the same token sometimes users
> accidentally commit files they didn't mean to, or forget to include
> files they meant to include. Showing a diffstat would also be a
> final sanity check for them.
Make it with -v.
If the --summary is already irritating to you, imagine how a diffstat
could be.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:40 ` Shawn Pearce
2006-12-15 15:50 ` Andreas Ericsson
2006-12-15 16:06 ` Nicolas Pitre
@ 2006-12-15 18:21 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 18:21 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> I do the same (diff a lot before commit) and thus find commit
> outputting anything at all to be noisy and irritating. Frankly
> the new
>
> git-diff-tree --summary --root --no-commit-id HEAD
>
> that Junio put on the end is already irritating.
>
> But it was added to help users verify that commit did what they
> thought it would (see 61f5cb7f).
The credit should go Pasky's way. Add/delete/mode are rarer
events and reminding them is sensible.
We do not show the 'summary' when we are concluding a merge that
conflicted. Otherwise you will be seeing other people's huge
changes that was just brought in.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 15:09 ` Shawn Pearce
2006-12-15 15:32 ` Andreas Ericsson
@ 2006-12-15 16:01 ` Nicolas Pitre
2006-12-15 16:08 ` Shawn Pearce
2006-12-15 18:14 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 16:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > It is nicer to let the user know when a commit succeeded all the time,
> > not only the first time. Also the commit sha1 is much more useful than
> > the tree sha1 in this case.
>
> I agree the commit sha1 is more useful than the tree sha1, but I'm
> not really sure its useful to show the commit sha1 post commit.
It is useful, even if it is not essential.
Since I believe it is a good thing to display _something_ by default
(and not only with -v as suggested -- please see the reasoning I posted
yesterday as to what should have some output and what shouldn't), it
doesn't hurt to display the commit sha1 as well.
First it has the very desirable side effect of making the user slightly
aware of how git identifies things. From the first commit a new user
will notice that git doesn't use any incremental version number but a
unique identifier that has nothing to do with sequence. It is not
expected that people will start _using_ the information printed, but it
will at least give a feel of how git works. And it is not like if the
whole thing took multiple lines to be displayed.
Next it _might_ be used by people. The fact that it is there might turn
to be useful. It is useful in the context of Documentation/tutorial-2.txt
for one where the notion of objects and their relationship is explained
based on the least amount of steps possible.
So in short I do think there should be something shown after a
successful commit, and including the commit sha1 doesn't hurt.
> If you want to show something the diffstat like what git merge does
> is better.
>
> For one thing it confirms that git accepted the changes. For another
> it shows you *which* changes it accepted. Plus it responds just
> like git-merge or git-pull does.
I disagree. My patch does confirm that git accepted the change with
only one line. As to which changes were accepted I think that when you
do the commit you certainly have a pretty good idea already of what is
going to be committed (you modified/added/removed files yourself, and by
default git-commit provides you with a summary in the text editor for
the commit message).
On Fri, 15 Dec 2006, Shawn Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
> > diffstats can be huge though. I'd rather have those only with -v option.
>
> But they are on by default for pull/merge, and disabled by -n.
>
> They are on to tell you what you just got during the pull/merge.
The pull/merge case is different. You are most likely to not know in
advance what the overall changes will be. Of course you're supposed to
know what you're pulling, but unlikely to know about the detail since
what you merge is remote to your current working tree by definition, and
even if you happen to be the one who did the changes in the other
branch/repo, it is certainly not as fresh in your mind than the changes
you did prior a commit.
And it is true that diffstat can be quite large. I wouldn't mind the
diffstat to be added to the commit message summary in the text editor
though. And displaying it when -v is used makes also a lot of sense.
But not by default please.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 16:01 ` Nicolas Pitre
@ 2006-12-15 16:08 ` Shawn Pearce
2006-12-15 18:14 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-15 16:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andreas Ericsson, Junio C Hamano, Andy Parkins, git
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 15 Dec 2006, Shawn Pearce wrote:
> > Andreas Ericsson <ae@op5.se> wrote:
> > > diffstats can be huge though. I'd rather have those only with -v option.
> >
> > But they are on by default for pull/merge, and disabled by -n.
>
> And it is true that diffstat can be quite large. I wouldn't mind the
> diffstat to be added to the commit message summary in the text editor
> though. And displaying it when -v is used makes also a lot of sense.
> But not by default please.
OK, two votes against diffstats by default in commit. Since I
haven't written a patch for it yet consider it dropped. ;-)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 16:01 ` Nicolas Pitre
2006-12-15 16:08 ` Shawn Pearce
@ 2006-12-15 18:14 ` Junio C Hamano
2006-12-15 20:13 ` Nicolas Pitre
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 18:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Andreas Ericsson, Andy Parkins, git
Nicolas Pitre <nico@cam.org> writes:
> So in short I do think there should be something shown after a
> successful commit, and including the commit sha1 doesn't hurt.
> ...
> And it is true that diffstat can be quite large. I wouldn't mind the
> diffstat to be added to the commit message summary in the text editor
> though. And displaying it when -v is used makes also a lot of sense.
> But not by default please.
I agree with everything you said in your message, including that
commit object name might help as a learning aid.
We could give something like this, though, if we wanted to:
$ git commit
4 files changed, 17 insertions(+), 10 deletions(-)
mode change 100755 => 100644 test.sh
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] make commit message a little more consistent and conforting
2006-12-15 18:14 ` Junio C Hamano
@ 2006-12-15 20:13 ` Nicolas Pitre
2006-12-16 6:18 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-15 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Andreas Ericsson, Andy Parkins, git
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > So in short I do think there should be something shown after a
> > successful commit, and including the commit sha1 doesn't hurt.
> > ...
> > And it is true that diffstat can be quite large. I wouldn't mind the
> > diffstat to be added to the commit message summary in the text editor
> > though. And displaying it when -v is used makes also a lot of sense.
> > But not by default please.
>
> I agree with everything you said in your message, including that
> commit object name might help as a learning aid.
>
> We could give something like this, though, if we wanted to:
>
> $ git commit
> 4 files changed, 17 insertions(+), 10 deletions(-)
> mode change 100755 => 100644 test.sh
Actually that would really be nice to have all the time for the
diff --summary output whenever --stat is not provided. Or maybe a
--shortstat option.
What about this (on top of my previous patch):
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9cdd171..f12082e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -21,6 +21,11 @@
deleted lines in decimal notation and pathname without
abbreviation, to make it more machine friendly.
+--shortstat::
+ Output only the last line of the --stat format containing total
+ number of modified files, as well as number of added and deleted
+ lines.
+
--summary::
Output a condensed summary of extended header information
such as creations, renames and mode changes.
diff --git a/diff.c b/diff.c
index 0b284b3..d754280 100644
--- a/diff.c
+++ b/diff.c
@@ -809,6 +809,35 @@ static void show_stats(struct diffstat_t* data, struct diff_options *options)
set, total_files, adds, dels, reset);
}
+static void show_shortstats(struct diffstat_t* data)
+{
+ int i, adds = 0, dels = 0, total_files = data->nr;
+
+ if (data->nr == 0)
+ return;
+
+ for (i = 0; i < data->nr; i++) {
+ if (!data->files[i]->is_binary &&
+ !data->files[i]->is_unmerged) {
+ int added = data->files[i]->added;
+ int deleted= data->files[i]->deleted;
+ if (!data->files[i]->is_renamed &&
+ (added + deleted == 0)) {
+ total_files--;
+ } else {
+ adds += added;
+ dels += deleted;
+ }
+ }
+ free(data->files[i]->name);
+ free(data->files[i]);
+ }
+ free(data->files);
+
+ printf(" %d files changed, %d insertions(+), %d deletions(-)\n",
+ total_files, adds, dels);
+}
+
static void show_numstat(struct diffstat_t* data, struct diff_options *options)
{
int i;
@@ -1767,6 +1796,7 @@ int diff_setup_done(struct diff_options *options)
options->output_format &= ~(DIFF_FORMAT_RAW |
DIFF_FORMAT_NUMSTAT |
DIFF_FORMAT_DIFFSTAT |
+ DIFF_FORMAT_SHORTSTAT |
DIFF_FORMAT_SUMMARY |
DIFF_FORMAT_PATCH);
@@ -1777,6 +1807,7 @@ int diff_setup_done(struct diff_options *options)
if (options->output_format & (DIFF_FORMAT_PATCH |
DIFF_FORMAT_NUMSTAT |
DIFF_FORMAT_DIFFSTAT |
+ DIFF_FORMAT_SHORTSTAT |
DIFF_FORMAT_SUMMARY |
DIFF_FORMAT_CHECKDIFF))
options->recursive = 1;
@@ -1868,6 +1899,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!strcmp(arg, "--numstat")) {
options->output_format |= DIFF_FORMAT_NUMSTAT;
}
+ else if (!strcmp(arg, "--shortstat")) {
+ options->output_format |= DIFF_FORMAT_SHORTSTAT;
+ }
else if (!strncmp(arg, "--stat", 6)) {
char *end;
int width = options->stat_width;
@@ -2642,7 +2676,7 @@ void diff_flush(struct diff_options *options)
separator++;
}
- if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_NUMSTAT)) {
+ if (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_SHORTSTAT|DIFF_FORMAT_NUMSTAT)) {
struct diffstat_t diffstat;
memset(&diffstat, 0, sizeof(struct diffstat_t));
@@ -2656,6 +2690,8 @@ void diff_flush(struct diff_options *options)
show_numstat(&diffstat, options);
if (output_format & DIFF_FORMAT_DIFFSTAT)
show_stats(&diffstat, options);
+ else if (output_format & DIFF_FORMAT_SHORTSTAT)
+ show_shortstats(&diffstat);
separator++;
}
diff --git a/diff.h b/diff.h
index 101b2b5..eff4455 100644
--- a/diff.h
+++ b/diff.h
@@ -29,6 +29,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_FORMAT_NUMSTAT 0x0004
#define DIFF_FORMAT_SUMMARY 0x0008
#define DIFF_FORMAT_PATCH 0x0010
+#define DIFF_FORMAT_SHORTSTAT 0x0020
/* These override all above */
#define DIFF_FORMAT_NAME 0x0100
diff --git a/git-commit.sh b/git-commit.sh
index 395bcd2..b9e49ea 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -629,7 +629,7 @@ then
if test -z "$quiet"
then
echo "Created${initial_commit:+ initial} commit $commit"
- git-diff-tree --summary --root --no-commit-id HEAD
+ git-diff-tree --shortstat --summary --root --no-commit-id HEAD
fi
fi
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 9:59 ` Andy Parkins
2006-12-14 10:21 ` Junio C Hamano
@ 2006-12-14 21:22 ` Junio C Hamano
2006-12-14 22:55 ` Andy Parkins
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 21:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
>> > Tell them if they
>> > made a branch as well, which branch they are now on.
>>
>> I think you are talking about "checkout -b" not commit here;
>> this might be a borderline (branch creation is less often done
>> and it might warrant assuring feedback), but I think it still
>> falls into the "doing exactly what it was told to do" category.
>
> You're right, I was. The reason I think feedback is useful is
> because of the two ways of making a new branch:
>
> - git-branch XYZ
> This makes a new branch but DOESN'T leave me on XYZ
> - git-commit -b XYZ
> This makes a new branch and switches to XYZ
>
> I can't tell you the number of times I get this wrong. It's not because I
> don't know if I stop to think, it's because I'm thinking about the project,
> not the VCS.
This is interesting. You said "commit -b", were pointed out
that you were talking about "checkout -b", and just after saying
"yup, that is right, I was", you again say "commit -b".
Maybe the users often need this sequence (I personally don't,
but others might):
$ git checkout ;# or the previous day ended with a clean state
$ edit edit hack
$ git checkout -b XYZ ;# the changes are about different stuff
$ git commit ;# commit the changes there
$ git checkout master ;# or whatever branch you usually are on
and "git commit -b <newbranch>" might be a handy shortcut for
the last three commands. I dunno.
And if we had such a variant of commit, then it is doing
something unusual, so I would not oppose (actually I would
probably favor) if the transcript went something like this:
$ git commit -b XYZ -m "implement 'foo' subcommand" -a
committed changes to newly created branch XYZ, back on 'master'.
$ git show-branch master XYZ
* [master] finishing touches to 'hello world'
! [XYZ] implement foo subcommand
--
+ [XYZ] implement foo subcommand
-- [master] finishing touches to 'hello world'
$ exit
Earlier I said that the command should be silent if it did
exactly what it was told to do with some 'unless'es.
* If the command fails, we should report (no question).
* If the command succeeds the usual way, staying silent is
preferable, at least to me.
* If the command can have more than one mode of successful
outcome, stating success in which way is not a useless
verbosity. E.g. 'git merge' should probably tell you if it
did a usual three-way or a fast-forward (if the difference
matters). Especially reporting an unusual case a bit more
verbosely than usual is a good thing.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 21:22 ` What's in git.git (stable) Junio C Hamano
@ 2006-12-14 22:55 ` Andy Parkins
2006-12-14 23:46 ` Junio C Hamano
2006-12-14 23:53 ` Johannes Schindelin
0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 22:55 UTC (permalink / raw)
To: git
On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
> This is interesting. You said "commit -b", were pointed out
> that you were talking about "checkout -b", and just after saying
> "yup, that is right, I was", you again say "commit -b".
There truly is something wrong with me. Is there some sort of record for
number of mistakes made in one thread? Have I won yet?
I'm not sure about your "commit -b"; is it wise to have /another/ way of
making a branch? I mean - I'm clearly confused enough, have a heart :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 22:55 ` Andy Parkins
@ 2006-12-14 23:46 ` Junio C Hamano
2006-12-15 8:58 ` Andy Parkins
2006-12-14 23:53 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-14 23:46 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
>> This is interesting. You said "commit -b", were pointed out
>> that you were talking about "checkout -b", and just after saying
>> "yup, that is right, I was", you again say "commit -b".
>
> There truly is something wrong with me.
I did not mean it that way. I only took it as a sign that maybe
"first create and switch to a branch and then work and commit
there, in separate steps", which is how git encourages things to
be done, does not match people's mental model so well.
> I'm not sure about your "commit -b"; is it wise to have /another/ way of
> making a branch? I mean - I'm clearly confused enough, have a heart :-)
I said "commit -b <newbranch>" and deliberately avoided saying
"commit -b <anybranch>", because I did not want to open another
can of worms while we are discussing so many good things
already, and my head can hold only a handful topics at once.
But people on the list (and #git channel) sometimes wished an
easy way to help the following workflow.
* I am in the middle of working on a new feature. As a good
git user, I am on a topic branch dedicated for that purpose.
* While working on it, I find an obvious bug that I would not
want to fix on the branch (the topic branch I am currently on
is not about fixing that bug).
* But I fix it in the working tree anyway, because otherwise I
would forget. It happens to be in an isolated file that my
current topic does not need to modify (say, I was looking at
a function in that file that my new feature needs to call and
I wanted to study its calling convention. And I found a typo in
the comment near the function).
* The fix does not belong to the current topic, but can go to
the 'master' branch straight. It's a fix in the comment that
cannot possibly break things, and I can/will test it later
anyway.
* So with the existing set of tools, I would go there, commit
and then come back:
$ git checkout [-m] master
$ git commit -m 'fix typo in that-file' that-file
$ git checkout [-m] topic
But it might be faster to say:
$ git commit -b master -m 'fix typo in that-file' that-file
to make a commit on the other branch and come back
immediately afterwards.
* In the same situation, when the 'master' is closed for some
administrative reason (e.g. "deep freeze before a release and
strict bugfixes and nothing else are allowed"), I would create
a new 'typofix' branch and do the same. I can rebase it
later on 'master' when it reopens.
$ git commit -b typofix -m 'fix typo in that-file' that-file
... much later when master reopens ...
$ git rebase --onto master topic typofix
It's just a possible typesaver, but I am likely not using it
myself (my fingers are already trained to do the three command
sequence dance).
I do agree that it adds one more way to do the same thing and
would make the documentation noisier, potentially adding more to
the confusion. So let's not go there.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 23:46 ` Junio C Hamano
@ 2006-12-15 8:58 ` Andy Parkins
2006-12-15 9:55 ` Raimund Bauer
2006-12-15 21:55 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-15 8:58 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
> > There truly is something wrong with me.
>
> I did not mean it that way. I only took it as a sign that maybe
Don't worry; I've got thicker skin than that. I was simply amazed at my lack
of comprehension ability. :-)
> > I'm not sure about your "commit -b"; is it wise to have /another/ way of
> > making a branch? I mean - I'm clearly confused enough, have a heart :-)
>
> I said "commit -b <newbranch>" and deliberately avoided saying
> "commit -b <anybranch>", because I did not want to open another
> can of worms while we are discussing so many good things
> already, and my head can hold only a handful topics at once.
Absolutely. I'd agree that only <newbranch> is worth even considering.
> * While working on it, I find an obvious bug that I would not
> want to fix on the branch (the topic branch I am currently on
> is not about fixing that bug).
I find myself swayed by this. This is indeed something that happens to me a
lot. In certain circumstances I've been defeated by git because I couldn't
switch to the other branch to make that quick commit because my local changes
conflicted with that other branch. The solution I use is to commit the bug
fix in the wrong branch, finish my current on-topic commit then
rebase/reset/etc to put everything where it should be.
> I do agree that it adds one more way to do the same thing and
> would make the documentation noisier, potentially adding more to
> the confusion. So let's not go there.
Yep. Although you've persuaded me with the above example, I think this is the
correct path. It's not wise to add every bell and whistle just because we
can. As long as there is /a/ way to achieve every task, that's good enough,
we don't need every way to achieve every task. We might even argue that
git's flexibility is what makes it harder to learn. It's similar to UNIX in
that respect - hard to learn, easy to use.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* RE: What's in git.git (stable)
2006-12-15 8:58 ` Andy Parkins
@ 2006-12-15 9:55 ` Raimund Bauer
2006-12-15 21:55 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Raimund Bauer @ 2006-12-15 9:55 UTC (permalink / raw)
To: 'Andy Parkins', git
> Yep. Although you've persuaded me with the above example, I
> think this is the
> correct path. It's not wise to add every bell and whistle
> just because we
> can. As long as there is /a/ way to achieve every task,
> that's good enough,
> we don't need every way to achieve every task. We might even
> argue that
> git's flexibility is what makes it harder to learn. It's
> similar to UNIX in
> that respect - hard to learn, easy to use.
So we prefer to tell users "You can do what you want with these 3 commands,
since we don't want to confuse use with another option to do it with just
1"?
> Andy
--
best regards
Ray
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 8:58 ` Andy Parkins
2006-12-15 9:55 ` Raimund Bauer
@ 2006-12-15 21:55 ` Junio C Hamano
2006-12-15 22:54 ` Carl Worth
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
> ...
>> I said "commit -b <newbranch>" and deliberately avoided saying
>> "commit -b <anybranch>", because I did not want to open another
>> can of worms while we are discussing so many good things
>> already, and my head can hold only a handful topics at once.
>
> Absolutely. I'd agree that only <newbranch> is worth even considering.
Just for the record, I do not necessarily agree. Committing a
small and obvious change out of context to an existing branch
makes just as much sense.
After all, with the example workflow in my message you responded
to, after running the "commit -b typofix" (which creates a new
branch) to record the first typo fix, I am sure that I would
want to record the second typofix I would find while on my topic
to go to the same typofix branch I previously created.
The 'can of worms' is that switching to an existing branch could
fail with conflicts. Although "git checkout -m" can help
sometimes, that is not something we would want to do in the
middle of doing something else on a topic. That's why I do not
think "commit -b <anybranch>" is a good idea.
Allowing the form for only a new branch makes an inconsistency
that is hard to explain to new people, and that is why I am not
in favor of having "commit -b <newbranch>" either.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 21:55 ` Junio C Hamano
@ 2006-12-15 22:54 ` Carl Worth
0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-12-15 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
> The 'can of worms' is that switching to an existing branch could
> fail with conflicts.
One fix for this would be the idea I've proposed to have a new flag
for "git checkout" to 'stash' the dirty state in the current branch
before switching.
Then, there wouldn't be a problem to implement "commit -b <anybranch>"
on top of the stashing checkout.
I think the only real problem with the idea of having dirty changes
stashed in a branch is that git already allows dirty changes to be
carried while switching to a branch, (with or without -m). And doing
both of those at once would lead to an ugly new conflict situation,
(where _neither_ of the conflicted states exist as exposed tree
objects). Even if there were no conflict, it would mingle two
different sets of local modifications, and that could be unkind as it
might be hard for the user to separate them if they didn't want them
mingled.
If someone were to pursue this idea, I think it would be reasonable to
just make that case an error, "Cannot carry local modifications when
checking out a branch with stashed modifications." That message could
even suggest the user use the stash option to leave the local
modifications behind when doing the checkout.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 22:55 ` Andy Parkins
2006-12-14 23:46 ` Junio C Hamano
@ 2006-12-14 23:53 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 23:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Hi,
On Thu, 14 Dec 2006, Andy Parkins wrote:
> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
> > This is interesting. You said "commit -b", were pointed out
> > that you were talking about "checkout -b", and just after saying
> > "yup, that is right, I was", you again say "commit -b".
>
> There truly is something wrong with me. Is there some sort of record
> for number of mistakes made in one thread? Have I won yet?
Honestly, I do not see anything you have done wrong. After all, a good
idea came from it.
> I'm not sure about your "commit -b"; is it wise to have /another/ way of
> making a branch? I mean - I'm clearly confused enough, have a heart :-)
I actually would _love_ that feature. Yeah, it's possible with existing
git commands, but it would be _convenient_.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 23:31 ` Junio C Hamano
` (3 preceding siblings ...)
2006-12-14 9:59 ` Andy Parkins
@ 2006-12-14 23:52 ` Horst H. von Brand
2006-12-15 10:53 ` Jakub Narebski
4 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-14 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
Junio C Hamano <junkio@cox.net> wrote:
[...]
> In general the principle ought to be not to say anything if the
> command does exactly what it was told to do successfully, unless
> the operation is expected to take longer than other normal
> commands in the git suite, or something that is rarely used.
Nodz. Just hoary Unix tradition.
> Perhaps under "[user] expert" control.
Nope. You'd be surprised what kind of people consider themselves
"experts"... I'd prefer adding -v/--verbose flags to all commands (if
nothing else, for symmetry's sake), have a '[default] --verbose' controlling
this across the board (perhaps also '[default "command"] --verbose'), with
'[default]' setting default switches.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 23:52 ` Horst H. von Brand
@ 2006-12-15 10:53 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 10:53 UTC (permalink / raw)
To: git
Horst H. von Brand wrote:
>> Perhaps under "[user] expert" control.
>
> Nope. You'd be surprised what kind of people consider themselves
> "experts"... I'd prefer adding -v/--verbose flags to all commands (if
> nothing else, for symmetry's sake), have a '[default] --verbose' controlling
> this across the board (perhaps also '[default "command"] --verbose'), with
> '[default]' setting default switches.
Nice idea... but configuration variables have to have name.
So it would be
$ git repo-config defaults.command --verbose
resulting in
[defaults]
command = --verbose
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 22:37 ` Andy Parkins
2006-12-13 22:48 ` Jakub Narebski
2006-12-13 23:31 ` Junio C Hamano
@ 2006-12-14 0:22 ` Johannes Schindelin
2006-12-14 10:21 ` Andy Parkins
2006-12-14 23:03 ` Shawn Pearce
3 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 0:22 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
Hi,
On Wed, 13 Dec 2006, Andy Parkins wrote:
> On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:
>
> * git-revert should be called git-invert. It doesn't remove a change
> from history, it simply applies another commit that does the
> opposite of whatever commit you are "revert"ing. That's an inversion.
No. An inversion is the _opposite_. Not an undo.
Besides, The fact that revert _adds_ to history is a nice way to
document that you reverted that change. And you can even explain in the
commit message, why you did it.
> * git-fetch output is confusing:
> remote: Generating pack...
> remote: Done counting 189146 objects.
> remote: Result has 186566 objects.
> remote: Deltifying 186566 objects.
> remote: 100% (186566/186566) done
> Unpacking 186566 objects
> 24% (44792/186566) done
> Some questions from the point of view of a newbie: what is a pack? what is
> an object? Why is the remote counting them? Which remote am I reading
> from? What am I fetching? What is "Deltifying"? How much data do I have
> to download (number of objects doesn't tell me). How long has this taken?
> How long is left to go?
IMHO it is better for a newbie to see that _something_ is happening. A
newbie cannot, and does not want to, understand exactly what is going on.
So, think of it as our response to Windows' non-progress-bar: when you
start up Windows, there is a progress-bar, except that it does not show
progress, but a Knight Rider like movement, only indicating that it does
something.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 0:22 ` Johannes Schindelin
@ 2006-12-14 10:21 ` Andy Parkins
2006-12-14 10:51 ` Johannes Schindelin
2006-12-14 17:23 ` Nicolas Pitre
0 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 10:21 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:
> > * git-revert should be called git-invert. It doesn't remove a change
> > from history, it simply applies another commit that does the
> > opposite of whatever commit you are "revert"ing. That's an inversion.
>
> No. An inversion is the _opposite_. Not an undo.
That's what I'm saying, we are applying the opposite of the given commit -
that commit is being inverted and applied again. It most certainly isn't an
undo, because the original commit still exists. It's not a reversion
because "reversion" is to regress to a previous time or state. In that sense
git-revert is not doing what it says on the tin. A revert would be to remove
all the revisions from now until the specified commit - i.e. what git-reset
now does.
(Note: I don't think git-reset should be renamed, as it's possible to use
git-reset to move a branch forward as well as backward).
> Besides, The fact that revert _adds_ to history is a nice way to
> document that you reverted that change. And you can even explain in the
> commit message, why you did it.
I'm not disputing that the /operation/ is useful, I'm arguing that it is
incorrectly named.
> IMHO it is better for a newbie to see that _something_ is happening. A
I'm not arguing that we should show nothing; I'm arguing that the something we
do show should be more clear than what is now shown. The choice is
therefore "show something confusing" or "show something clear".
> newbie cannot, and does not want to, understand exactly what is going on.
"newbie" doesn't mean "idiot". Everybody wants to understand what is going
on.
> So, think of it as our response to Windows' non-progress-bar: when you
> start up Windows, there is a progress-bar, except that it does not show
> progress, but a Knight Rider like movement, only indicating that it does
> something.
Given the choice between nothing and a non-progress "doing something" bar, I
would of course pick the "doing something" bar. However, given the choice
between a "doing something" bar and a progress bar, I'd rather have the
progress bar.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:21 ` Andy Parkins
@ 2006-12-14 10:51 ` Johannes Schindelin
2006-12-14 11:23 ` Andy Parkins
2006-12-15 0:15 ` Horst H. von Brand
2006-12-14 17:23 ` Nicolas Pitre
1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 10:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Hi,
On Thu, 14 Dec 2006, Andy Parkins wrote:
> On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:
>
> > > * git-revert should be called git-invert. It doesn't remove a change
> > > from history, it simply applies another commit that does the
> > > opposite of whatever commit you are "revert"ing. That's an inversion.
> >
> > No. An inversion is the _opposite_. Not an undo.
>
> That's what I'm saying, we are applying the opposite of the given commit
> - that commit is being inverted and applied again.
Ahh! I get what you are thinking. I was talking about reverting a change
from the _content's viewpoint_. I _never_ want to revert history (I am no
politician, you know?)
> > newbie cannot, and does not want to, understand exactly what is going
> > on.
>
> "newbie" doesn't mean "idiot". Everybody wants to understand what is
> going on.
I heartly disagree. I saw so many faces _begging_ me to just say _what_ to
do, not _why_, and quickly, please.
> > So, think of it as our response to Windows' non-progress-bar: when you
> > start up Windows, there is a progress-bar, except that it does not
> > show progress, but a Knight Rider like movement, only indicating that
> > it does something.
>
> Given the choice between nothing and a non-progress "doing something"
> bar, I would of course pick the "doing something" bar. However, given
> the choice between a "doing something" bar and a progress bar, I'd
> rather have the progress bar.
If I have the choice between a "doing something" bar and a Windows
Explorer "14 seconds left" bar showing the same message for two minutes,
I'd rather have a Mars bar ;-)
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:51 ` Johannes Schindelin
@ 2006-12-14 11:23 ` Andy Parkins
2006-12-14 11:27 ` Johannes Schindelin
2006-12-15 0:15 ` Horst H. von Brand
1 sibling, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 11:23 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:
> If I have the choice between a "doing something" bar and a Windows
> Explorer "14 seconds left" bar showing the same message for two minutes,
> I'd rather have a Mars bar ;-)
Gahhhhhhhhh! Oh how I hate that window.
On this we can wholeheartedly agree. Unfortunately it's not just windows;
most applications that have a progress bar go like this:
0%, ..., 0%,..., 0%,.., 1 , 2, 3, 4, 5, 6, 33%, ..., 33%, ..., 33%, 35, 36,
85%, ..., 85%, ..., 85%, ..., 99%, 100%, ..., 100%, ... (yes, I'm completely
finished, but still working), ... 100%.
I reckon, unless the window with a progress bar in it has an ETA, then the
progress should be an ETA itself. If it's not going to monotonically
increase, then the "percentage" is meaningless.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:23 ` Andy Parkins
@ 2006-12-14 11:27 ` Johannes Schindelin
2006-12-14 12:00 ` Andy Parkins
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-14 11:27 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Hi,
On Thu, 14 Dec 2006, Andy Parkins wrote:
> On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:
>
> > If I have the choice between a "doing something" bar and a Windows
> > Explorer "14 seconds left" bar showing the same message for two minutes,
> > I'd rather have a Mars bar ;-)
>
> Gahhhhhhhhh! Oh how I hate that window.
>
> On this we can wholeheartedly agree. Unfortunately it's not just windows;
> most applications that have a progress bar go like this:
>
> 0%, ..., 0%,..., 0%,.., 1 , 2, 3, 4, 5, 6, 33%, ..., 33%, ..., 33%, 35, 36,
> 85%, ..., 85%, ..., 85%, ..., 99%, 100%, ..., 100%, ... (yes, I'm completely
> finished, but still working), ... 100%.
>
> I reckon, unless the window with a progress bar in it has an ETA, then the
> progress should be an ETA itself. If it's not going to monotonically
> increase, then the "percentage" is meaningless.
And now you know one of the reasons we have no true progress bar.
Another reason is that it would be relatively expensive to calculate,
since the total _size_ is not known beforehand (remember, the pack is
calculated on the fly).
Yet another reason is that all estimates there are unstable by nature: the
load of the server, the net load, the load of the client, the speed of
packing and unpacking, and the luck if deltas can be reused, are all
contributors to this unstability.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 11:27 ` Johannes Schindelin
@ 2006-12-14 12:00 ` Andy Parkins
2006-12-14 12:10 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 12:00 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 11:27, Johannes Schindelin wrote:
> And now you know one of the reasons we have no true progress bar.
>
> Another reason is that it would be relatively expensive to calculate,
> since the total _size_ is not known beforehand (remember, the pack is
> calculated on the fly).
Hmmm; just thinking out loud now... I used to calculate ETA's for simulations
I ran that had similar problems - i.e. you don't know how long it takes until
its done (it was with genetic programming function trees, and of course you
don't know what operations will be in the next generations tree, so you can't
estimate a time). I just showed "something" by doing a standard: how long
did n/N take therefore N will take... then I plotted the error in the ETA
after the simulation completed. Interestingly it was always a -exp(-x)
shape. In other words it got more accurate towards the end (of course);
which is exactly the sort of accuracy you would want. At the beginning you
just want a broad "this will take a few hours" measure. Towards the end, you
want to know "there is 1m50s remaining".
I wonder if the number of objects is a reasonable measure of progress. Let's
say we're transferring 100,000 objects. Let's also say that the average size
of objects is 100 bytes. Let's finally say that the object sizes are evenly
distributed throughout the 100,000 objects. This would mean that the first
1,000 objects are just as representative as the last 1,000 objects; or any
other randomly chosen 1,000 objects. In which case, the size of the first
thousand objects would be approximately one hundredth the size of the total
transfer. Volia: an estimate of the total size of the transfer.
Obviously this estimate would be continuously updated, and would become more
accurate as more objects are transferred. The data rate would of course be
based on only the previous X objects rather than the total transferred to
take account of changing server conditions. From these ETA could be
estimated.
Obviously the ETA is unstable, but it's only for giving users an idea of how
long is left; not for strict accounting.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 12:00 ` Andy Parkins
@ 2006-12-14 12:10 ` Shawn Pearce
2006-12-14 13:20 ` Andy Parkins
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 12:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> wrote:
> I wonder if the number of objects is a reasonable measure of progress. Let's
> say we're transferring 100,000 objects. Let's also say that the average size
> of objects is 100 bytes. Let's finally say that the object sizes are evenly
> distributed throughout the 100,000 objects. This would mean that the first
> 1,000 objects are just as representative as the last 1,000 objects; or any
> other randomly chosen 1,000 objects. In which case, the size of the first
> thousand objects would be approximately one hundredth the size of the total
> transfer. Volia: an estimate of the total size of the transfer.
Ah, but much like those stock scam emails, "prior performance does
not predict future results"... The size of objects in the pack
tends to be small up front (commits/trees) and larger in the back
(blobs). The size distribution probably also gets more erratic
near the back as the blob sizes may not follow a nice distribution.
E.g. I have a repository with a blob that is 23 MiB. But I also
have some 5 MiB blobs, and then a very large number of relatively
small blobs. That 23 MiB blob really gums up any estimate.
But as you state, its easy to refine it over time, and the closer we
get to the end the more likely it is to be correct. Unless its that
23 MiB blob. As it takes up about 85% of that repository's pack.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 12:10 ` Shawn Pearce
@ 2006-12-14 13:20 ` Andy Parkins
0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 13:20 UTC (permalink / raw)
To: git
On Thursday 2006 December 14 12:10, Shawn Pearce wrote:
> not predict future results"... The size of objects in the pack
> tends to be small up front (commits/trees) and larger in the back
> (blobs). The size distribution probably also gets more erratic
> near the back as the blob sizes may not follow a nice distribution.
Oh well; that pretty much settles it then.
> But as you state, its easy to refine it over time, and the closer we
> get to the end the more likely it is to be correct. Unless its that
> 23 MiB blob. As it takes up about 85% of that repository's pack.
I had imagined (foolishly), that most objects would be diffs, and would be
similarly sized.
Scratch that.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:51 ` Johannes Schindelin
2006-12-14 11:23 ` Andy Parkins
@ 2006-12-15 0:15 ` Horst H. von Brand
2006-12-15 0:23 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-15 0:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Andy Parkins wrote:
[...]
> > "newbie" doesn't mean "idiot". Everybody wants to understand what is
> > going on.
> I heartly disagree. I saw so many faces _begging_ me to just say _what_ to
> do, not _why_, and quickly, please.
So? This is meant to be a /tool/. Not wanting to know how it works doesn't
make one an idiot, it is just economy.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 0:15 ` Horst H. von Brand
@ 2006-12-15 0:23 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 0:23 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Andy Parkins, git
Hi,
On Thu, 14 Dec 2006, Horst H. von Brand wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 14 Dec 2006, Andy Parkins wrote:
>
> [...]
>
> > > "newbie" doesn't mean "idiot". Everybody wants to understand what is
> > > going on.
>
> > I heartly disagree. I saw so many faces _begging_ me to just say _what_ to
> > do, not _why_, and quickly, please.
>
> So? This is meant to be a /tool/. Not wanting to know how it works doesn't
> make one an idiot, it is just economy.
My thoughts exactly.
And I did not want to force understanding onto the users. Heck, I even
know people who use git and do not know about the index! They don't need
to, either.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 10:21 ` Andy Parkins
2006-12-14 10:51 ` Johannes Schindelin
@ 2006-12-14 17:23 ` Nicolas Pitre
2006-12-14 21:02 ` Andy Parkins
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-14 17:23 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Thu, 14 Dec 2006, Andy Parkins wrote:
> > Besides, The fact that revert _adds_ to history is a nice way to
> > document that you reverted that change. And you can even explain in the
> > commit message, why you did it.
>
> I'm not disputing that the /operation/ is useful, I'm arguing that it is
> incorrectly named.
Well, people are used to say they've "reverted" a change. Although the
command might appear slightly misnamed wrt its operation, it still does
what most people are expecting from such a name.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 17:23 ` Nicolas Pitre
@ 2006-12-14 21:02 ` Andy Parkins
0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-12-14 21:02 UTC (permalink / raw)
To: git
On Thursday 2006, December 14 17:23, Nicolas Pitre wrote:
> Well, people are used to say they've "reverted" a change. Although the
> command might appear slightly misnamed wrt its operation, it still does
> what most people are expecting from such a name.
Actually , not only is git-revert misnamed, it doesn't match up with most
other SCMs.
"svn revert" is git-reset.
"bzr revert" is git-reset.
"darcs revert" is git-reset.
"hg revert" is git-reset.
"svk revert" is git-reset.
"monotone revert" is git-reset.
Most people must surely be expecting it to do what it does in every other SCM;
as it doesn't my argument is that we should just drop the name "revert" and
call it git-invert instead, which is more accurately named and doesn't
conflict with the standard meaning.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 22:37 ` Andy Parkins
` (2 preceding siblings ...)
2006-12-14 0:22 ` Johannes Schindelin
@ 2006-12-14 23:03 ` Shawn Pearce
2006-12-15 16:16 ` Jakub Narebski
3 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-14 23:03 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
Andy Parkins <andyparkins@gmail.com> wrote:
> * git-show-branch output is cryptic.
Agreed. I still don't know how to read its output. So I just
don't use it. Ever. :-)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-14 23:03 ` Shawn Pearce
@ 2006-12-15 16:16 ` Jakub Narebski
2006-12-15 21:55 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 16:16 UTC (permalink / raw)
To: git
Shawn Pearce wrote:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> * git-show-branch output is cryptic.
>
> Agreed. I still don't know how to read its output. So I just
> don't use it. Ever. :-)
And the way it uses it's options is even more cryptic, and differs from
other similar commands. So I'd rather use qgit (or gitk, if gitk would
correct the error with remembering wrong window size).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 16:16 ` Jakub Narebski
@ 2006-12-15 21:55 ` Junio C Hamano
2006-12-15 22:48 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: jnareb, Andy Parkins, git
Jakub Narebski <jnareb@gmail.com> writes:
> Shawn Pearce wrote:
>
>> Andy Parkins <andyparkins@gmail.com> wrote:
>>> * git-show-branch output is cryptic.
>>
>> Agreed. I still don't know how to read its output. So I just
>> don't use it. Ever. :-)
>
> And the way it uses it's options is even more cryptic, and differs from
> other similar commands.
(Jakub, please do not drop people from cc: list; you were asked
more than once).
Ok, so what's the action you guys are proposing?
(1) show-branch output is cryptic and it does not do anything
useful. Drop it.
(2) show-branch output is cryptic and I do not understand what
it is trying to do. Document it better.
(3) While I agree what show-branch is trying to do is useful,
its output is useless. Instead of showing an example
situation like this:
[ picture here ]
It should show the same situation like this:
[ improved picture here ]
(4) None of the above.
The same question goes for its input branch specification.
Personally, I find its input branch globbing very handy, and
often wish that 'git branch' had a '--list' option that lists
branches that match the glob pattern given on the command line,
not just listing everything when no parameter is given.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 21:55 ` Junio C Hamano
@ 2006-12-15 22:48 ` Jakub Narebski
2006-12-15 23:25 ` Johannes Schindelin
2006-12-15 23:42 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-15 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Andy Parkins, git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Shawn Pearce wrote:
>>
>>> Andy Parkins <andyparkins@gmail.com> wrote:
>>>> * git-show-branch output is cryptic.
>>>
>>> Agreed. I still don't know how to read its output. So I just
>>> don't use it. Ever. :-)
>>
>> And the way it uses it's options is even more cryptic, and differs from
>> other similar commands.
>
> (Jakub, please do not drop people from cc: list; you were asked
> more than once).
The problem is that I'm not subscribed to git mailing list; I usually
read it via GMane news<->mail interface, at
nntp://news.gmane.org/gmane.comp.version-control.git
First, in this interface I have only the last author and not the full
Cc: list. Second, when I reply _both_ via email (adding authors if
necessary) and to news, people receiving my reply don't have (I guess)
git@vger.kernel.org in Cc: list, so sometimes the discussion drops off
the list. Third, if I add git mailing list address when replying via
mail, vger server blocks email from gmane stating
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 9): 501 5.1.3 Path data: Had characters unsuitable for an rfc821-string
When email is sent _directly_ to me (i.e. I'm on Cc: list) I try
to preserve Cc: list.
> Ok, so what's the action you guys are proposing?
>
> (1) show-branch input is cryptic and it does not do anything
> useful. Drop it.
>
> (2) show-branch input is cryptic and I do not understand what
> it is trying to do. Document it better.
[...]
I'm just used to the way revisions are specified to other history
viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch
is a bit odd man out here. "git-show-branch ref1 ref2 ref3"
is (without --more=n) like
git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)
Which is handy for git-show-branch, but odd. Perhaps we should add
--xor option to git rev list for the above, i.e.
git rev-list A...B ==
== git rev-list A B --not $(git merge-base A B)
git rev-list --xor A B C ==
== git rev-list A B C --not $(git merge-base A B C)
> Personally, I find its input branch globbing very handy, and
> often wish that 'git branch' had a '--list' option that lists
> branches that match the glob pattern given on the command line,
> not just listing everything when no parameter is given.
It is odd (git branch not having --list with globbing) also because
'git tag' has globbing support.
--
Jakub Narebski
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 22:48 ` Jakub Narebski
@ 2006-12-15 23:25 ` Johannes Schindelin
2006-12-15 23:45 ` Junio C Hamano
2006-12-15 23:42 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-15 23:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
Hi,
On Fri, 15 Dec 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > (Jakub, please do not drop people from cc: list; you were asked
> > more than once).
>
> The problem is that I'm not subscribed to git mailing list;
So subscribe. I am sure I lost quite some of your responses to my emails,
_just_ because you happen to kill me from the Cc: list.
IOW if you expect answers, _please_ adher to net standards.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 23:25 ` Johannes Schindelin
@ 2006-12-15 23:45 ` Junio C Hamano
2006-12-16 0:14 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 23:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jakub Narebski
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 15 Dec 2006, Jakub Narebski wrote:
>
>> Junio C Hamano wrote:
>>
>> > (Jakub, please do not drop people from cc: list; you were asked
>> > more than once).
>>
>> The problem is that I'm not subscribed to git mailing list;
>
> So subscribe. I am sure I lost quite some of your responses to my emails,
> _just_ because you happen to kill me from the Cc: list.
>
> IOW if you expect answers, _please_ adher to net standards.
FWIW, I also read the list traffic through gmane news gateway.
I am subscribed and my mail filter drops the mails from the list
into a dedicated mailbox, but that is purely for my own backup
and I usually do not look at it otherwise.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 23:45 ` Junio C Hamano
@ 2006-12-16 0:14 ` Johannes Schindelin
2006-12-16 0:30 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
Hi,
On Fri, 15 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 15 Dec 2006, Jakub Narebski wrote:
> >
> >> Junio C Hamano wrote:
> >>
> >> > (Jakub, please do not drop people from cc: list; you were asked
> >> > more than once).
> >>
> >> The problem is that I'm not subscribed to git mailing list;
> >
> > So subscribe. I am sure I lost quite some of your responses to my emails,
> > _just_ because you happen to kill me from the Cc: list.
> >
> > IOW if you expect answers, _please_ adher to net standards.
>
> FWIW, I also read the list traffic through gmane news gateway.
So, how do you tackle the problem Jakub evidently has, namely to reply to
all the people who your reply refers to?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-16 0:14 ` Johannes Schindelin
@ 2006-12-16 0:30 ` Junio C Hamano
2006-12-16 17:12 ` Steven Grimm
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 0:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jakub Narebski
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> FWIW, I also read the list traffic through gmane news gateway.
>
> So, how do you tackle the problem Jakub evidently has, namely to reply to
> all the people who your reply refers to?
I do not "tackle".
I just tell Gnus to follow-up, which does not always do the
right thing [*1*], and I just try to be careful and fix up To:
and Cc: fields by hand as necessary. The time spent on that on
my part is _worth_ spending than inconveniencing others.
It's just a common courtesy, not "tackling".
[Footnote]
*1* ... most likely because I haven't configured it to do the
right thing, and/or the sender or the gateway puts a wrong
Reply-To: or Mail-Followup-To: header and it ends up honoring
them.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-16 0:30 ` Junio C Hamano
@ 2006-12-16 17:12 ` Steven Grimm
2006-12-16 19:57 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2006-12-16 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Jakub Narebski
Junio C Hamano wrote:
> It's just a common courtesy, not "tackling".
>
Interesting. I'd actually prefer people *remove* me from the CC list --
I find it annoying to get two copies of every message in threads I reply
to. I'm already subscribed to the mailing list, so there's no point
having me on the Cc line too. (Mind you, as annoyances go it's a pretty
insignificant one.)
I can understand the case of people who aren't on the list wanting to
get replies, but why does someone who *is* on the list want to be CCed?
Is it just that there's no good way to tell in advance which category a
given person falls into, so best to be on the safe side?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-16 17:12 ` Steven Grimm
@ 2006-12-16 19:57 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 19:57 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, git, Jakub Narebski
Steven Grimm <koreth@midwinter.com> writes:
> Interesting. I'd actually prefer people *remove* me from the CC list --
> I find it annoying to get two copies of every message in threads I
> reply to. I'm already subscribed to the mailing list, so there's no
> point having me on the Cc line too. (Mind you, as annoyances go it's a
> pretty insignificant one.)
>
> I can understand the case of people who aren't on the list wanting to
> get replies, but why does someone who *is* on the list want to be
> CCed? Is it just that there's no good way to tell in advance which
> category a given person falls into, so best to be on the safe side?
There is no cheap and mechanical way to tell that for the
sender, and even when the sender can tell, it is not polite to
do so (see next paragraph), unless the recipient specifically
ask for it. On the other hand, filtering duplicates at the
recipient's end could be mechanically done without wasting the
human time. And people's time tend to be a lot more expensive
than machine time and the cost to send extra bits over the wire.
Some people (including me) prioritize e-mails and respond to
messages that are addressed To: them first, then Cc: next, and
finally the rest of the messages that came only through the
mailng list. Dropping a recipient from the Cc: list, even when
the sender knows that recipient is on the list, breaks this.
People can safely remove *themselves* from the CC: list when the
mailing list they subscribe to are on the CC: list as well.
This would interact with the prioritizing I mentioned above, but
that is done as a choice by them as the recipient of the
replies, so there is no problem in doing so.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-15 22:48 ` Jakub Narebski
2006-12-15 23:25 ` Johannes Schindelin
@ 2006-12-15 23:42 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-15 23:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn Pearce, Andy Parkins, git
Jakub Narebski <jnareb@gmail.com> writes:
> I'm just used to the way revisions are specified to other history
> viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch
> is a bit odd man out here. "git-show-branch ref1 ref2 ref3"
> is (without --more=n) like
>
> git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)
>
> Which is handy for git-show-branch, but odd.
I hate to sound harsh, but...
Then you do not understand show-branch at all. Not having to
say the "--not merge-base" part is NOT about being handy, but is
the central part of what show-branch does. The command is about
showing the commits that are on only some of the branches but
not on others.
Other commands you listed above are all based on rev-list logic
of painting commits in two colors (either UNINTERESTING or
~UNINTERESTING) and being able to combine the set using "A..B",
"^A B", and "A B --not C" notations all make sense. All
combinations work as set operation -- start from union of
commits reachable from positive (i.e. not prefixed with ^) refs,
and subtract set of commits reachable from any negative ref.
What show-branch does cannot be expressed with that two-color
logic; it needs to use N colors for N input refs. After digging
from the tips deep enough, you would find the common merge-base
and after that point it is not interesting to show anything
anymore, and that is how it stops output.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] git-clone: use wildcard specification for tracking branches
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
2006-12-13 22:37 ` Andy Parkins
@ 2006-12-16 9:14 ` Junio C Hamano
2006-12-16 9:36 ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
2006-12-16 9:39 ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
2006-12-16 9:58 ` What's in git.git (stable) Junio C Hamano
2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
3 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 9:14 UTC (permalink / raw)
To: git
This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file. Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.
Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.
Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace. But that is Ok; it
will be going away before v1.5.0.
We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed. That should also
be in v1.5.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Things that need to be done to complete what have been merged to
> 'master' are:
> ...
> - 'git-clone' probably should be updated to use wild-card in
> remote.origin.fetch, instead of listing all the branches it
> found when the clone was made.
git-clone.sh | 47 ++++++++++++++++++++++++++++++-----------------
1 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 1f5d07a..422499a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -366,41 +366,54 @@ then
)
)
- # Write out remotes/$origin file, and update our "$head_points_at".
+ # Write out remote.$origin config, and update our "$head_points_at".
case "$head_points_at" in
?*)
- mkdir -p "$GIT_DIR/remotes" &&
+ # Local default branch
git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
+
+ # Tracking branch for the primary branch at the remote.
case "$use_separate_remote" in
t) origin_track="$remote_top/$head_points_at"
git-update-ref HEAD "$head_sha1" ;;
*) origin_track="$remote_top/$origin"
git-update-ref "refs/heads/$origin" "$head_sha1" ;;
esac &&
+
+ # Upstream URL and the primary branch tracking
git-repo-config remote."$origin".url "$repo" &&
git-repo-config remote."$origin".fetch \
"refs/heads/$head_points_at:$origin_track" &&
- (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
- while read dotslref
- do
- name=`expr "$dotslref" : './\(.*\)'`
- if test "z$head_points_at" = "z$name"
- then
- continue
- fi
- if test "$use_separate_remote" = '' &&
- test "z$origin" = "z$name"
- then
- continue
- fi
- git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}" '^$'
- done &&
+
+ # Set up the mappings to track the remaining branches.
+ case "$use_separate_remote" in
+ t)
+ git-repo-config remote."$origin".fetch \
+ "refs/heads/*:$remote_top/*" '^$'
+ ;;
+ *)
+ (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+ while read dotslref
+ do
+ name=`expr "$dotslref" : './\(.*\)'`
+ if test "z$head_points_at" = "z$name" ||
+ test "z$origin" = "z$name"
+ then
+ continue
+ fi
+ git-repo-config remote."$origin".fetch \
+ "refs/heads/${name}:$remote_top/${name}" '^$'
+ done
+ ;;
+ esac &&
+
case "$use_separate_remote" in
t)
rm -f "refs/remotes/$origin/HEAD"
git-symbolic-ref "refs/remotes/$origin/HEAD" \
"refs/remotes/$origin/$head_points_at"
esac &&
+
git-repo-config branch."$head_points_at".remote "$origin" &&
git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
esac
^ permalink raw reply related [flat|nested] 601+ messages in thread
* [PATCH] git-pull: refuse default merge without branch.*.merge
2006-12-16 9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
@ 2006-12-16 9:36 ` Junio C Hamano
2006-12-16 9:41 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
2006-12-16 16:44 ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
2006-12-16 9:39 ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 9:36 UTC (permalink / raw)
To: git
Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch. This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.
The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> We could also lose the "primary branch" mapping at the
> beginning, but that has to wait until we implement the "forbid
> 'git pull' when we do not have branch.$current.merge for the
> current branch" policy we earlier discussed. That should also
> be in v1.5.0
And this does exactly that.
git-parse-remote.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 6ae534b..7cd79c2 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -144,7 +144,8 @@ canon_refs_list_for_fetch () {
curr_branch=$(git-symbolic-ref HEAD | \
sed -e 's|^refs/heads/||')
merge_branches=$(git-repo-config \
- --get-all "branch.${curr_branch}.merge")
+ --get-all "branch.${curr_branch}.merge") ||
+ merge_branches=.this.would.never.match.any.ref.
fi
set x $(expand_refs_wildcard "$@")
shift
^ permalink raw reply related [flat|nested] 601+ messages in thread
* [PATCH] git-clone: lose the artificial "first" fetch refspec
2006-12-16 9:36 ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
@ 2006-12-16 9:41 ` Junio C Hamano
2006-12-16 9:53 ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
2006-12-16 11:51 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
2006-12-16 16:44 ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 9:41 UTC (permalink / raw)
To: git
Now we lost the "first refspec is the one that is merged by default"
rule, there is no reason for clone to list the remote primary branch
in the config file explicitly anymore.
We still need it for the traditional layout for other reasons,
though.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
> Junio C Hamano <junkio@cox.net> writes:
>
>> We could also lose the "primary branch" mapping at the
>> beginning, but that has to wait until we implement the "forbid
>> 'git pull' when we do not have branch.$current.merge for the
>> current branch" policy we earlier discussed. That should also
>> be in v1.5.0
>
> And this does exactly that.
Next step will be to remove the traditional layout altogether.
With the recent flurry of UI updates, I think it is sane to do
that before v1.5.0; opinions?
git-clone.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 422499a..68dc4f2 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -380,18 +380,18 @@ then
git-update-ref "refs/heads/$origin" "$head_sha1" ;;
esac &&
- # Upstream URL and the primary branch tracking
+ # Upstream URL
git-repo-config remote."$origin".url "$repo" &&
- git-repo-config remote."$origin".fetch \
- "refs/heads/$head_points_at:$origin_track" &&
- # Set up the mappings to track the remaining branches.
+ # Set up the mappings to track the remote branches.
case "$use_separate_remote" in
t)
git-repo-config remote."$origin".fetch \
"refs/heads/*:$remote_top/*" '^$'
;;
*)
+ git-repo-config remote."$origin".fetch \
+ "refs/heads/$head_points_at:$origin_track" &&
(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
while read dotslref
do
^ permalink raw reply related [flat|nested] 601+ messages in thread
* [PATCH] git-clone: lose the traditional 'no-separate-remote' layout
2006-12-16 9:41 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
@ 2006-12-16 9:53 ` Junio C Hamano
2006-12-16 16:53 ` Linus Torvalds
2006-12-16 11:51 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 9:53 UTC (permalink / raw)
To: git
Finally.
The separate-remote layout is so much more organized than
traditional and easier to work with especially when you need to
deal with remote repositories with multiple branches and/or you
need to deal with more than one remote repositories, and using
traditional layout for new repositories simply does not make
much sense.
Internally we still have code for 1:1 mappings to create a bare
clone; that is a good thing and will not go away.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Next step will be to remove the traditional layout altogether.
> With the recent flurry of UI updates, I think it is sane to do
> that before v1.5.0; opinions?
And this drops it; modulo bugs, I think this is about it for
v1.5.0 around this area.
Documentation/git-clone.txt | 15 +----------
git-clone.sh | 58 +++++++++----------------------------------
2 files changed, 13 insertions(+), 60 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index bfddb21..874934a 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,8 +11,7 @@ SYNOPSIS
[verse]
'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--use-separate-remote | --no-separate-remote] <repository>
- [<directory>]
+ <repository> [<directory>]
DESCRIPTION
-----------
@@ -99,18 +98,6 @@ OPTIONS
if unset the templates are taken from the installation
defined default, typically `/usr/share/git-core/templates`.
---use-separate-remote::
- Save remotes heads under `$GIT_DIR/refs/remotes/origin/` instead
- of `$GIT_DIR/refs/heads/`. Only the local master branch is
- saved in the latter. This is the default.
-
---no-separate-remote::
- Save remotes heads in the same namespace as the local
- heads, `$GIT_DIR/refs/heads/'. In regular repositories,
- this is a legacy setup git-clone created by default in
- older Git versions, and will be removed before the next
- major release.
-
<repository>::
The (possibly remote) repository to clone from. It can
be any URL git-fetch supports.
diff --git a/git-clone.sh b/git-clone.sh
index 68dc4f2..490f3e4 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--no-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
}
get_repo_base() {
@@ -137,11 +137,9 @@ while
*,--template=*)
template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
- *,--use-separate-remote)
- # default
- use_separate_remote=t ;;
+ *,--use-separate-remote) ;;
*,--no-separate-remote)
- use_separate_remote= ;;
+ die "clones are always made with separate-remote layout" ;;
1,--reference) usage ;;
*,--reference)
shift; reference="$1" ;;
@@ -327,12 +325,8 @@ cd "$D" || exit
if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
then
- # Figure out which remote branch HEAD points at.
- case "$use_separate_remote" in
- '') remote_top=refs/heads ;;
- *) remote_top="refs/remotes/$origin" ;;
- esac
-
+ # a non-bare repository is always in separate-remote layout
+ remote_top="refs/remotes/$origin"
head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
case "$head_sha1" in
'ref: refs/'*)
@@ -373,46 +367,18 @@ then
git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
# Tracking branch for the primary branch at the remote.
- case "$use_separate_remote" in
- t) origin_track="$remote_top/$head_points_at"
- git-update-ref HEAD "$head_sha1" ;;
- *) origin_track="$remote_top/$origin"
- git-update-ref "refs/heads/$origin" "$head_sha1" ;;
- esac &&
+ origin_track="$remote_top/$head_points_at" &&
+ git-update-ref HEAD "$head_sha1" &&
# Upstream URL
git-repo-config remote."$origin".url "$repo" &&
# Set up the mappings to track the remote branches.
- case "$use_separate_remote" in
- t)
- git-repo-config remote."$origin".fetch \
- "refs/heads/*:$remote_top/*" '^$'
- ;;
- *)
- git-repo-config remote."$origin".fetch \
- "refs/heads/$head_points_at:$origin_track" &&
- (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
- while read dotslref
- do
- name=`expr "$dotslref" : './\(.*\)'`
- if test "z$head_points_at" = "z$name" ||
- test "z$origin" = "z$name"
- then
- continue
- fi
- git-repo-config remote."$origin".fetch \
- "refs/heads/${name}:$remote_top/${name}" '^$'
- done
- ;;
- esac &&
-
- case "$use_separate_remote" in
- t)
- rm -f "refs/remotes/$origin/HEAD"
- git-symbolic-ref "refs/remotes/$origin/HEAD" \
- "refs/remotes/$origin/$head_points_at"
- esac &&
+ git-repo-config remote."$origin".fetch \
+ "refs/heads/*:$remote_top/*" '^$' &&
+ rm -f "refs/remotes/$origin/HEAD"
+ git-symbolic-ref "refs/remotes/$origin/HEAD" \
+ "refs/remotes/$origin/$head_points_at" &&
git-repo-config branch."$head_points_at".remote "$origin" &&
git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [PATCH] git-clone: lose the artificial "first" fetch refspec
2006-12-16 9:41 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
2006-12-16 9:53 ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
@ 2006-12-16 11:51 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Sat, 16 Dec 2006, Junio C Hamano wrote:
> With the recent flurry of UI updates, I think it is sane to do
> that before v1.5.0; opinions?
Answering to all of your recent patches in this direction: I like it.
Originally, I thought that this would require more from me: I often
synchronize my git repository (including topic branches) between different
machines back and forth, via usb stick, and two different central
machines. I use the script I sent in this mail:
http://article.gmane.org/gmane.comp.version-control.git/6956/
However, I just realized that I will not need the script anymore, what
with the recent addition of wildcards to remote.<branch>.fetch. Good job!
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] git-pull: refuse default merge without branch.*.merge
2006-12-16 9:36 ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
2006-12-16 9:41 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
@ 2006-12-16 16:44 ` Linus Torvalds
1 sibling, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-12-16 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> Everybody hated the pull behaviour of merging the first branch
> listed on remotes/* file (or remote.*.fetch config) into the
> current branch. This finally corrects that UI wart by
> forbidding "git pull" without an explicit branch name on the
> command line or branch.$current.merge for the current branch.
Yay!
May I suggest also just merging the built-in 3-way merge, and just calling
the resulting version 1.5.0?
With all the "git add" and documentation cleanups, and these kinds of
fundamental changes in behaviour (not that anybody will hopefully
_notice_, and if they do they'll hopefully just be grateful, but it's
still conceptually a big step), I think it's definitely worth a new
version number.
Maybe even "2.0", although since we're still backwards compatible in all
ways that really matter, a major number might be too big a step.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] git-clone: use wildcard specification for tracking branches
2006-12-16 9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
2006-12-16 9:36 ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
@ 2006-12-16 9:39 ` Jakub Narebski
1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-16 9:39 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> This stops enumerating the set of branches found on the remote
> side when a clone was made in the configuration file. Instead,
> a single entry that maps each remote branch to the local
> tracking branch for the remote under the same name is created.
>
> Doing it this way not only shortens the configuration file, but
> automatically adjusts to a new branch added on the remote side
> after the clone is made.
[...]
Does this deal with non-fast-forward branches like 'pu'? Does
it add $head_points_at at the beginning, before glob... wait,
this is not needed if there is branch.$head_points_at.merge.
But perhaps it still would be better to have:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
fetch = refs/heads/*:refs/remotes/origin/*
fetch =+refs/heads/pu:refs/remotes/origin/pu
[branch "master"]
remote = origin
merge = refs/heads/master ;# full spec of remote branch
But this is very nice. Thanks.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
2006-12-13 22:37 ` Andy Parkins
2006-12-16 9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
@ 2006-12-16 9:58 ` Junio C Hamano
2006-12-16 11:22 ` [PATCH] Document git-merge-file Johannes Schindelin
2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
3 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 9:58 UTC (permalink / raw)
To: git
>> I am hoping that we can start a stabilization cycle for v1.5.0
>> based on what we have in 'master'. The theme is "usability and
>> teachability".
>>
>> Things that need to be done to complete what have been merged to
>> 'master' are:
>>
>> - 'git-rm' needs to be fixed up as Linus outlined; remove
>> working tree file and index entry but have a sanity check to
>> make sure the working tree file match the index and HEAD.
>>
>> - 'git-branch' may need to be taught about renaming the
>> matching per-branch configuration at the same time.
>>
>> - 'git-merge-file' needs to be documented and linked from
>> git.txt.
>>
>> - 'git-clone' probably should be updated to use wild-card in
>> remote.origin.fetch, instead of listing all the branches it
>> found when the clone was made.
>>
>> - tutorials and other Porcelain documentation pages need to be
>> updated to match the updated 'git-add' and 'git-rm' (to be
>> updated), and their description should be made much less
>> about implementation; they should talk in terms of end-user
>> workflows. I will send a draft for 'git diff' out later, but
>> somebody needs a full sweep on Porcelain-ish documentation.
>>
>> - 'git diff --index' patch should be reverted (already done in
>> 'next'), although we may have to come up with a better
>> wording for --cached.
I'm done with 2 out of the above six ("diff --index", and
"clone") and a bit of the "documentation" item so far, and will
go to bed now. Any takers for the remaining tasks while I'll be
sleeping ;-)?
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] Document git-merge-file
2006-12-16 9:58 ` What's in git.git (stable) Junio C Hamano
@ 2006-12-16 11:22 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-16 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Most of this is derived from the documentation of RCS merge.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sat, 16 Dec 2006, Junio C Hamano wrote:
> >> - 'git-merge-file' needs to be documented and linked from
> >> git.txt.
Documentation/git-merge-file.txt | 92 ++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 +
2 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
new file mode 100644
index 0000000..0b41d66
--- /dev/null
+++ b/Documentation/git-merge-file.txt
@@ -0,0 +1,92 @@
+git-merge-file(1)
+============
+
+NAME
+----
+git-merge-file - threeway file merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+ [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
+
+
+DESCRIPTION
+-----------
+git-file-merge incorporates all changes that lead from the `<base-file>`
+to `<other-file>` into `<current-file>`. The result ordinarily goes into
+`<current-file>`. git-merge-file is useful for combining separate changes
+to an original. Suppose `<base-file>` is the original, and both
+`<current-file>` and `<other-file>` are modifications of `<base-file>`.
+Then git-merge-file combines both changes.
+
+A conflict occurs if both `<current-file>` and `<other-file>` have changes
+in a common segment of lines. If a conflict is found, git-merge-file
+normally outputs a warning and brackets the conflict with <<<<<<< and
+>>>>>>> lines. A typical conflict will look like this:
+
+ <<<<<<< A
+ lines in file A
+ =======
+ lines in file B
+ >>>>>>> B
+
+If there are conflicts, the user should edit the result and delete one of
+the alternatives.
+
+The exit value of this program is negative on error, and the number of
+conflicts otherwise. If the merge was clean, the exit value is 0.
+
+git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+implements all of RCS merge's functionality which is needed by
+gitlink:git[1].
+
+
+OPTIONS
+-------
+
+-L <label>::
+ This option may be given up to three times, and
+ specifies labels to be used in place of the
+ corresponding file names in conflict reports. That is,
+ `git-merge-file -L x -L y -L z a b c` generates output that
+ looks like it came from files x, y and z instead of
+ from files a, b and c.
+
+-p::
+ Send results to standard output instead of overwriting
+ `<current-file>`.
+
+-q::
+ Quiet; do not warn about conflicts.
+
+
+EXAMPLES
+--------
+
+git merge-file README.my README README.upstream::
+
+ combines the changes of README.my and README.upstream since README,
+ tries to merge them and writes the result into README.my.
+
+git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
+
+ merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
+ `a` and `c` instead of `tmp/a123` and `tmp/c345`.
+
+
+Author
+------
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
+
+Documentation
+--------------
+Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
+with parts copied from the original documentation of RCS merge.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index b9b1e63..b9fc9ae 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -359,6 +359,9 @@ gitlink:git-init-db[1]::
Creates an empty git object database, or reinitialize an
existing one.
+gitlink:git-merge-file[1]::
+ Runs a threeway merge.
+
gitlink:git-merge-index[1]::
Runs a merge for files needing merging.
--
1.4.4.2.g5dc03
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
` (2 preceding siblings ...)
2006-12-16 9:58 ` What's in git.git (stable) Junio C Hamano
@ 2006-12-16 13:59 ` Jakub Narebski
2006-12-16 22:04 ` Junio C Hamano
3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-16 13:59 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Junio C Hamano wrote:
> Things that need to be done to complete what have been merged to
> 'master' are:
What about discussed but not implemented moving restriction on non-head refs
from git-checkout (forbidding to checkout tags, remotes, and arbitrary
commits like HEAD~n) to git-commit (allowing commiting only to heads refs)?
Probably non-heads refs should be saved in HEAD as explicit sha1 of a
commit; this way we wont run into situation where HEAD changed under us
(because it was for example to remote branch, and we fetched since).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
@ 2006-12-16 22:04 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Things that need to be done to complete what have been merged to
>> 'master' are:
>
> What about discussed but not implemented moving restriction on non-head refs
> from git-checkout (forbidding to checkout tags, remotes, and arbitrary
> commits like HEAD~n) to git-commit (allowing commiting only to heads refs)?
Did I miss a patch? ;-)
I've taken a look at it once, and it is usually easy to decide
if we should allow or disallow manipulation of the HEAD at
individual places that tries to look at it or modify it, but
there are many places and giving reasonable error messages to
all of the places we would want to disallow would be quite a lot
of work. In other words, it is rather a wide-and-shallow change
all over manipulators section of Porcelain. So from my point of
view it is backburnered, but that does not mean I would object
to a patch that does it cleanly ;-).
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2008-07-21 7:09 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-07-21 7:09 UTC (permalink / raw)
To: git
As announced in a separate message, the tip of master was tagged as
1.6.0-rc0; for people who neglected futureproofing themselves so far, it
would really be a good time to seriously consider doing so.
* The 'maint' branch has these fixes since the last announcement.
Jonathan Nieder (1):
fix usage string for git grep
Junio C Hamano (1):
refresh-index: fix bitmask assignment
* The 'master' branch has these since the last announcement
in addition to the above.
Avery Pennarun (1):
Reword "your branch has diverged..." lines to reduce line length
Dmitry Potapov (1):
git-svn: fix git svn info to work without arguments
Junio C Hamano (8):
rerere.autoupdate: change the message when autoupdate is in effect
builtin-add.c: restructure the code for maintainability
git-add --all: add all files
git-add --all: tests
git-add --all: documentation
Link shell with compat layer functions
Move read_in_full() and write_in_full() to wrapper.c
"needs update" considered harmful
Lars Noschinski (1):
cvsserver: Add testsuite for packed refs
Michele Ballabio (2):
builtin-merge.c: Fix option parsing
builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
Miklos Vajna (1):
Teach 'git merge' that some merge strategies no longer exist
Nanako Shiraishi (1):
git am --abort
^ permalink raw reply [flat|nested] 601+ messages in thread
* [ANNOUNCE] GIT 1.5.5
@ 2008-04-09 6:51 Junio C Hamano
2008-04-09 9:44 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-09 6:51 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.5.5 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.5.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.5-1.$arch.rpm (RPM)
We kept this cycle just slightly over two months, as the previous 1.5.4
cycle was painfully tooooo long.
GIT v1.5.5 Release Notes
========================
Updates since v1.5.4
--------------------
(subsystems)
* Comes with git-gui 0.10.1
(portability)
* We shouldn't ask for BSD group ownership semantics by setting g+s bit
on directories on older BSD systems that refuses chmod() by non root
users. BSD semantics is the default there anyway.
* Bunch of portability improvement patches coming from an effort to port
to Solaris has been applied.
(performance)
* On platforms with suboptimal qsort(3) implementation, there
is an option to use more reasonable substitute we ship with
our software.
* New configuration variable "pack.packsizelimit" can be used
in place of command line option --max-pack-size.
* "git fetch" over the native git protocol used to make a
connection to find out the set of current remote refs and
another to actually download the pack data. We now use only
one connection for these tasks.
* "git commit" does not run lstat(2) more than necessary
anymore.
(usability, bells and whistles)
* Bash completion script (in contrib) are aware of more commands and
options.
* You can be warned when core.autocrlf conversion is applied in
such a way that results in an irreversible conversion.
* A catch-all "color.ui" configuration variable can be used to
enable coloring of all color-capable commands, instead of
individual ones such as "color.status" and "color.branch".
* The commands refused to take absolute pathnames where they
require pathnames relative to the work tree or the current
subdirectory. They now can take absolute pathnames in such a
case as long as the pathnames do not refer outside of the
work tree. E.g. "git add $(pwd)/foo" now works.
* Error messages used to be sent to stderr, only to get hidden,
when $PAGER was in use. They now are sent to stdout along
with the command output to be shown in the $PAGER.
* A pattern "foo/" in .gitignore file now matches a directory
"foo". Pattern "foo" also matches as before.
* bash completion's prompt helper function can talk about
operation in-progress (e.g. merge, rebase, etc.).
* Configuration variables "url.<usethis>.insteadof = <otherurl>" can be
used to tell "git-fetch" and "git-push" to use different URL than what
is given from the command line.
* "git add -i" behaves better even before you make an initial commit.
* "git am" refused to run from a subdirectory without a good reason.
* After "git apply --whitespace=fix" fixes whitespace errors in a patch,
a line before the fix can appear as a context or preimage line in a
later patch, causing the patch not to apply. The command now knows to
see through whitespace fixes done to context lines to successfully
apply such a patch series.
* "git branch" (and "git checkout -b") to branch from a local branch can
optionally set "branch.<name>.merge" to mark the new branch to build on
the other local branch, when "branch.autosetupmerge" is set to
"always", or when passing the command line option "--track" (this option
was ignored when branching from local branches). By default, this does
not happen when branching from a local branch.
* "git checkout" to switch to a branch that has "branch.<name>.merge" set
(i.e. marked to build on another branch) reports how much the branch
and the other branch diverged.
* When "git checkout" has to update a lot of paths, it used to be silent
for 4 seconds before it showed any progress report. It is now a bit
more impatient and starts showing progress report early.
* "git commit" learned a new hook "prepare-commit-msg" that can
inspect what is going to be committed and prepare the commit
log message template to be edited.
* "git cvsimport" can now take more than one -M options.
* "git describe" learned to limit the tags to be used for
naming with --match option.
* "git describe --contains" now barfs when the named commit
cannot be described.
* "git describe --exact-match" describes only commits that are tagged.
* "git describe --long" describes a tagged commit as $tag-0-$sha1,
instead of just showing the exact tagname.
* "git describe" warns when using a tag whose name and path contradict
with each other.
* "git diff" learned "--relative" option to limit and output paths
relative to the current directory when working in a subdirectory.
* "git diff" learned "--dirstat" option to show birds-eye-summary of
changes more concisely than "--diffstat".
* "git format-patch" learned --cover-letter option to generate a cover
letter template.
* "git gc" learned --quiet option.
* "git gc" now automatically prunes unreachable objects that are two
weeks old or older.
* "git gc --auto" can be disabled more easily by just setting gc.auto
to zero. It also tolerates more packfiles by default.
* "git grep" now knows "--name-only" is a synonym for the "-l" option.
* "git help <alias>" now reports "'git <alias>' is alias to <what>",
instead of saying "No manual entry for git-<alias>".
* "git help" can use different backends to show manual pages and this can
be configured using "man.viewer" configuration.
* "gitk" does not restore window position from $HOME/.gitk anymore (it
still restores the size).
* "git log --grep=<what>" learned "--fixed-strings" option to look for
<what> without treating it as a regular expression.
* "git gui" learned an auto-spell checking.
* "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as
expected; they push the current branch (and only the current branch).
In addition, HEAD can be written as the value of "remote.<there>.push"
configuration variable.
* When the configuration variable "pack.threads" is set to 0, "git
repack" auto detects the number of CPUs and uses that many threads.
* "git send-email" learned to prompt for passwords
interactively.
* "git send-email" learned an easier way to suppress CC
recipients.
* "git stash" learned "pop" command, that applies the latest stash and
removes it from the stash, and "drop" command to discard the named
stash entry.
* "git submodule" learned a new subcommand "summary" to show the
symmetric difference between the HEAD version and the work tree version
of the submodule commits.
* Various "git cvsimport", "git cvsexportcommit", "git cvsserver",
"git svn" and "git p4" improvements.
(internal)
* Duplicated code between git-help and git-instaweb that
launches user's preferred browser has been refactored.
* It is now easier to write test scripts that records known
breakages.
* "git checkout" is rewritten in C.
* "git remote" is rewritten in C.
* Two conflict hunks that are separated by a very short span of common
lines are now coalesced into one larger hunk, to make the result easier
to read.
* Run-command API's use of file descriptors is documented clearer and
is more consistent now.
* diff output can be sent to FILE * that is different from stdout. This
will help reimplementing more things in C.
Fixes since v1.5.4
------------------
All of the fixes in v1.5.4 maintenance series are included in
this release, unless otherwise noted.
* "git-http-push" did not allow deletion of remote ref with the usual
"push <remote> :<branch>" syntax.
* "git-rebase --abort" did not go back to the right location if
"git-reset" was run during the "git-rebase" session.
* "git imap-send" without setting imap.host did not error out but
segfaulted.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-04-09 6:51 [ANNOUNCE] GIT 1.5.5 Junio C Hamano
@ 2008-04-09 9:44 ` Junio C Hamano
2008-04-14 7:00 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-09 9:44 UTC (permalink / raw)
To: git
* The 'master' branch has these since v1.5.5.
Frank Lichtenheld (4):
var: Don't require to be in a git repository.
Git.pm: Don't require a repository instance for config
Git.pm: Don't require repository instance for ident
send-email: Don't require to be called in a repository
Gerrit Pape (2):
gitweb: fallback to system-wide config file if default config does not
exist
gitweb: fallback to system-wide config file (fixup)
Govind Salinas (1):
pretty.c: add %x00 format specifier.
Jeff King (2):
add--interactive: ignore mode change in 'p'atch command
add--interactive: allow user to choose mode update
Junio C Hamano (4):
Optimize rename detection for a huge diff
t5300: add test for "unpack-objects --strict"
unpack-objects: fix --strict handling
rebase [--onto O] A B: omit needless checkout
Martin Koegler (3):
unpack-objects: prevent writing of inconsistent objects
receive-pack: allow using --strict mode for unpacking objects
t5300: add test for "index-pack --strict"
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-04-09 9:44 ` What's in git.git (stable) Junio C Hamano
@ 2008-04-14 7:00 ` Junio C Hamano
2008-04-19 8:18 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-14 7:00 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since v1.5.5; perhaps v1.5.5.1 mid
next week.
Björn Steinbrink (1):
Fix section about backdating tags in the git-tag docs
Carlos Rica (2):
Fix documentation syntax of optional arguments in short options.
core-tutorial.txt: Fix showing the current behaviour.
Christian Couder (2):
bisect: fix bad rev checking in "git bisect good"
bisect: report bad rev better
Clifford Caoile (1):
Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)
Daniel Barkalow (1):
Fix config key miscount in url.*.insteadOf
Dirk Suesserott (1):
Documentation/git-request-pull: Fixed a typo ("send" -> "end")
Jeff King (1):
git-fetch: fix status output when not storing tracking ref
Johannes Sixt (1):
Document option --only of git commit
Junio C Hamano (3):
Document -w option to shortlog
Documentation/git-submodule: typofix
t7401: squelch garbage output
Michele Ballabio (1):
revision.c: make --date-order overriddable
Pedro Melo (1):
Force the medium pretty format on calls to git log
Ping Yin (1):
git-submodule: Avoid 'fatal: cannot describe' message
René Scharfe (1):
git-archive: ignore prefix when checking file attribute
* The 'master' branch has these since the last announcement
in addition to the above.
Christian Couder (1):
bisect: add "git bisect help" subcommand to get a long usage string
Johannes Sixt (1):
builtin-commit.c: Remove a redundant assignment.
Junio C Hamano (1):
git_config_bool_or_int()
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-04-14 7:00 ` Junio C Hamano
@ 2008-04-19 8:18 ` Junio C Hamano
2008-04-27 6:04 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-19 8:18 UTC (permalink / raw)
To: git
As quite some fixes have accumulated on 'maint', I am planning to do
1.5.5.1 this Sunday with what is in 'maint', perhaps with the 'rebase: do
not munge commit log message' fix that is in 'master' tonight.
* The 'maint' branch has these fixes since the last announcement.
Alberto Bertogli (1):
builtin-apply: Show a more descriptive error on failure when opening a
patch
Christian Couder (2):
bisect: squelch "fatal: ref HEAD not a symref" misleading message
git-bisect: make "start", "good" and "skip" succeed or fail atomically
Jakub Narebski (1):
gitweb: Fix 'history' view for deleted files with history
Jon Loeliger (1):
Clarify and fix English in "git-rm" documentation
Jonas Fonseca (1):
git-remote: reject adding remotes with invalid names
Junio C Hamano (2):
git-am: minor cleanup
am: POSIX portability fix
Linus Torvalds (2):
Ignore leading empty lines while summarizing merges
git-am: cope better with an empty Subject: line
Mark Levedahl (1):
git-submodule - possibly use branch name to describe a module
Matthieu Moy (1):
Document that WebDAV doesn't need git on the server, and works over SSL
Scott Collins (1):
Clarify documentation of git-cvsserver, particularly in relation to
git-shell
Shawn Bohrer (2):
git clean: Don't automatically remove directories when run within
subdirectory
git clean: Add test to verify directories aren't removed with a prefix
* The 'master' branch has these since the last announcement
in addition to the above.
Christian Couder (1):
bisect: add "git bisect help" subcommand to get a long usage string
Johannes Sixt (1):
builtin-commit.c: Remove a redundant assignment.
Junio C Hamano (3):
git_config_bool_or_int()
Fix git_config_bool_or_int
rebase: do not munge commit log message
Stephan Beyer (1):
builtin-apply.c: use git_config_string() to get apply_default_whitespace
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-04-19 8:18 ` Junio C Hamano
@ 2008-04-27 6:04 ` Junio C Hamano
2008-05-06 6:38 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-27 6:04 UTC (permalink / raw)
To: git
Post 1.5.5 maintenance track is getting stable and more boring ;-).
* The 'maint' branch has these fixes since v1.5.5.1
Andy Parkins (1):
post-receive-email: fix accidental removal of a trailing space in
signature line
Ariel Badichi (2):
copy.c: copy_fd - correctly report write errors
archive.c: format_subst - fixed bogus argument to memchr
Brandon Casey (1):
git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc
Dmitry Potapov (1):
git-gc --prune is deprecated
Gerrit Pape (1):
diff-options.txt: document the new "--dirstat" option
Jeff King (5):
Don't force imap.host to be set when imap.tunnel is set
t5516: remove ambiguity test (1)
doc/git-gc: add a note about what is collected
push: allow unqualified dest refspecs to DWIM
remote: create fetch config lines with '+'
Junio C Hamano (1):
write-tree: properly detect failure to write tree objects
Matt Graham (1):
Linked glossary from cvs-migration page
Matthew Ogilvie (1):
gitattributes: Fix subdirectory attributes specified from root directory
Michael Weber (1):
svn-git: Use binmode for reading/writing binary rev maps
Miklos Vajna (1):
diff options documentation: refer to --diff-filter in --name-status
Sam Vilain (1):
Amend git-push refspec documentation
Teemu Likonen (1):
bash: Add completion for git diff --base --ours --theirs
Thomas Guyot-Sionnest (1):
git-svn bug with blank commits and author file
martin f. krafft (2):
Escape project name in regexp
Escape project names before creating pathinfo URLs
* The 'master' branch has these since the last announcement
in addition to the above.
Clifford Caoile (1):
git.el: Set process-environment instead of invoking env
Dan McGee (2):
completion: allow 'git remote' subcommand completion
completion: remove use of dashed git commands
Heikki Orsila (1):
Make core.sharedRepository more generic
Jeff King (1):
git-remote: show all remotes with "git remote show"
Junio C Hamano (5):
sha1-lookup: more memory efficient search in sorted list of SHA-1
diff: make --dirstat binary-file safe
sha1-lookup: make selection of 'middle' less aggressive
log: teach "terminator" vs "separator" mode to "--pretty=format"
First batch of post 1.5.5 updates
Matthias Kestenholz (1):
Use color.ui variable in scripts too
Miklos Vajna (3):
git-gc --auto: add pre-auto-gc hook
Documentation/hooks: add pre-auto-gc hook
contrib/hooks: add an example pre-auto-gc hook
Ping Yin (3):
git-submodule summary: --for-status option
builtin-status: submodule summary support
builtin-status: Add tests for submodule summary
Rafael Garcia-Suarez (1):
Spelling fixes in the gitweb documentation
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-04-27 6:04 ` Junio C Hamano
@ 2008-05-06 6:38 ` Junio C Hamano
2008-05-14 22:35 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-06 6:38 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (2):
Use "=" instead of "==" in condition as it is more portable
Fix use after free() in builtin-fetch
Dan McGee (1):
Remove 'header' from --signoff option description
Florian Ragwitz (1):
filter-branch: Documentation fix.
Jeff King (3):
fix reflog approxidate parsing bug
cvsimport: always pass user data to "system" as a list
checkout: don't rfc2047-encode oneline on detached HEAD
Junio C Hamano (2):
clone: detect and fail on excess parameters
fetch-pack: brown paper bag fix
Linus Torvalds (1):
fetch-pack: do not stop traversing an already parsed commit
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Simpkins (2):
Remove dead code: show_log() sep argument and diff_options.msg_sep
log: print log entry terminator even if the message is empty
Alex Riesen (1):
Use the modern syntax of git-diff-files in t2002-checkout-cache-u.sh
Bart Trojanowski (1):
make git-status use a pager
Brandon Casey (1):
filter-branch.sh: support nearly proper tag name filtering
Christian Couder (3):
rev-parse: teach "--verify" to be quiet when using "-q" or "--quiet"
rev-parse: fix --verify to error out when passed junk after a good rev
Documentation: hooks: fix missing verb in pre-applypatch description
Gustaf Hendeby (2):
git-svn: Make create-ignore use git add -f
Documentation: Add create-ignore to git svn manual
Heikki Orsila (4):
Document functions xmemdupz(), xread() and xwrite()
Die for an early EOF in a file reading loop
Make read_in_full() and write_in_full() consistent with xread() and
xwrite()
Cleanup xread() loops to use read_in_full()
Jeff King (2):
git-fetch: always show status of non-tracking-ref fetches
Documentation: point git-prune users to git-gc
Jon Loeliger (1):
Add otherwise missing --strict option to unpack-objects summary.
Junio C Hamano (2):
write_index(): optimize ce_smudge_racily_clean_entry() calls with
CE_UPTODATE
diff-files: mark an index entry we know is up-to-date as such
Jörg Sommer (1):
post-merge: Add it's not executed if merge failed.
Lars Hjemli (7):
Add platform-independent .git "symlink"
Teach resolve_gitlink_ref() about the .git file
Teach git-submodule.sh about the .git file
Teach GIT-VERSION-GEN about the .git file
git-branch: add support for --merged and --no-merged
git-branch.txt: compare --contains, --merged and --no-merged
Add tests for `branch --[no-]merged`
Liu Yubao (1):
Documentation on --git-dir and --work-tree
Matthieu Moy (1):
git-svn: detect and fail gracefully when dcommitting to a void
Miklos Vajna (2):
git checkout: add -t alias for --track
INSTALL: add a note about GNU interactive tools has been renamed
Paolo Bonzini (1):
Add a remote.*.mirror configuration option
Richard Quirk (2):
bash: Add completion for gitk --merge
Documentation gitk: Describe what --merge does
Stephen R. van den Berg (1):
git-svn: Same default as cvsimport when using --use-log-author
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-05-06 6:38 ` Junio C Hamano
@ 2008-05-14 22:35 ` Junio C Hamano
2008-05-24 1:32 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-14 22:35 UTC (permalink / raw)
To: git
The largest change to 'master' in this round is Linus's case insensitivity
changes. I wanted to get feedback and fixes (if needed) from case
insensitive folks while the topic was still in 'next', but it did not
happen, but this should at least not harm sane filesystems, so let's see
how it goes.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
A Large Angry SCM (1):
git-repack: re-enable parsing of -n command line option
Dustin Sallings (1):
Documentation/config.txt: Mention branch.<name>.rebase applies to "git
pull"
Ian Hilt (1):
Documentation/git-describe.txt: make description more readable
Jeff King (1):
doc: clarify definition of "update" for git-add -u
Johannes Sixt (1):
wt-status.h: declare global variables as extern
Sitaram Chamarty (1):
builtin-commit.c: add -u as short name for --untracked-files
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Improve reporting of errors in config file routines
Brandon Casey (1):
compat/fopen.c: avoid clobbering the system defined fopen macro
Bryan Donlan (10):
git-rebase.sh: Fix --merge --abort failures when path contains whitespace
config.c: Escape backslashes in section names properly
git-send-email.perl: Handle shell metacharacters in $EDITOR properly
test-lib.sh: Add a test_set_editor function to safely set $VISUAL
Use test_set_editor in t9001-send-email.sh
test-lib.sh: Fix some missing path quoting
lib-git-svn.sh: Fix quoting issues with paths containing shell
metacharacters
Don't use the 'export NAME=value' in the test scripts.
Fix tests breaking when checkout path contains shell metacharacters
Rename the test trash directory to contain spaces.
Caio Marcelo de Oliveira Filho (1):
git-format-patch: add --no-binary to omit binary changes in the patch.
Christian Couder (12):
help: use man viewer path from "man.<tool>.path" config var
documentation: help: add "man.<tool>.path" config variable
help: use "man.<tool>.cmd" as custom man viewer command
documentation: help: add info about "man.<tool>.cmd" config var
documentation: web--browse: add a note about konqueror
Documentation: rename "hooks.txt" to "githooks.txt" and make it a man
page
Documentation: improve "add", "pull" and "format-patch" examples
Documentation: bisect: add a few "git bisect run" examples
bisect: print an error message when "git rev-list --bisect-vars" fails
rev-parse: add test script for "--verify"
rev-parse: fix using "--default" with "--verify"
rev-parse --verify: do not output anything on error
Dan McGee (1):
Allow cherry-pick (and revert) to add signoff line
Daniel Barkalow (2):
Make walker.fetch_ref() take a struct ref.
Make ls-remote http://... list HEAD, like for git://...
Dustin Sallings (1):
Allow tracking branches to set up rebase by default.
Eric Wong (1):
git-svn: fix cloning of HTTP URLs with '+' in their path
Gerrit Pape (1):
git-bisect.sh: don't accidentally override existing branch "bisect"
Gustaf Hendeby (1):
Documentation/config.txt: Add git-gui options
Jakub Narebski (1):
gitweb: Use feed link according to current view
Jeff King (7):
add merge.renamelimit config option
bump rename limit defaults
diff: make "too many files" rename warning optional
fix bsd shell negation
t5000: tar portability fix
clone: bsd shell portability fix
filter-branch: fix variable export logic
Johannes Sixt (1):
compat-util: avoid macro redefinition warning
Junio C Hamano (3):
diff: a submodule not checked out is not modified
diff-lib.c: rename check_work_tree_entity()
is_racy_timestamp(): do not check timestamp for gitlinks
Krzysztof Kowalczyk (1):
alloc_ref_from_str(): factor out a common pattern of alloc_ref from
string
Linus Torvalds (12):
Make unpack_trees_options bit flags actual bitfields
Move name hashing functions into a file of its own
Make "index_name_exists()" return the cache_entry it found
Make hash_name_lookup able to do case-independent lookups
Add 'core.ignorecase' option
Make branch merging aware of underlying case-insensitive filsystems
Make unpack-tree update removed files before any updated files
When adding files to the index, add support for case-independent matches
Make git-add behave more sensibly in a case-insensitive environment
Optimize match_pathspec() to avoid fnmatch()
Avoid some unnecessary lstat() calls
Optimize symlink/directory detection
Mark Hills (1):
Be more careful with objects directory permissions on clone
Miklos Vajna (3):
git-format-patch: add a new format.cc configuration variable
git-send-email: add a new sendemail.cc configuration variable
Add tests for sendemail.cc configuration variable
Ping Yin (2):
t4027: test diff for submodule with empty directory
Add t7506 to test submodule related functions for git-status
SZEDER Gábor (5):
doc: moved merge.* config variables into separate merge-config.txt
merge, pull: introduce '--(no-)stat' option
add 'merge.stat' config variable
fmt-merge-msg: add '--(no-)log' options and 'merge.log' config variable
merge, pull: add '--(no-)log' command line option
Santi Béjar (3):
Preparation to call determine_author_info from prepare_to_commit
commit: Show author if different from committer
commit: Show committer if automatic
Sebastian Schuberth (1):
mergetool: Make ECMerge use the settings as specified by the user in the
GUI
Steven Grimm (1):
Add svn-compatible "blame" output format to git-svn
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-05-14 22:35 ` Junio C Hamano
@ 2008-05-24 1:32 ` Junio C Hamano
2008-05-30 20:43 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-24 1:32 UTC (permalink / raw)
To: git
Quite a many topics have graduated to 'master' and hopefully we can tag
1.5.6-rc0 this weekend. At about the same time I'll do 1.5.5.2 out of
'maint' branch, as it has accumulated quite a few fixes as well.
* The 'maint' branch has these fixes since the last announcement.
Heikki Orsila (1):
Add missing "short" alternative to --date in rev-list-options.txt
Jeff King (2):
doc/git-daemon: s/uploadarchive/uploadarch/
git-am: fix typo in usage message
Johannes Sixt (1):
rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
Jon Loeliger (2):
git-filter-branch: Clarify file removal example.
git-show.txt: Not very stubby these days.
Shawn O. Pearce (1):
Clarify repack -n documentation
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Simpkins (4):
revision API: split parent rewriting and parent printing options
Add history graph API
log and rev-list: add --graph option
graph API: eliminate unnecessary indentation
Alex Riesen (7):
Make the exit code of add_file_to_index actually useful
Extend interface of add_files_to_cache to allow ignore indexing errors
Add --ignore-errors to git-add to allow it to skip files with read errors
Add a test for git-add --ignore-errors
Add a config option to ignore errors for git-add
Ensure that a test is run in the trash directory
Fix t3701 if core.filemode disabled
Anders Waldenborg (1):
gitweb: Convert string to internal form before chopping in chop_str
Brandon Casey (4):
repack: modify behavior of -A option to leave unreferenced objects
unpacked
git-gc: always use -A when manually repacking
builtin-gc.c: deprecate --prune, it now really has no effect
t/Makefile: "trash" directory was renamed recently
Chris Frey (2):
Documentation/git-prune.txt: document unpacked logic
Documentation/git-repack.txt: document new -A behaviour
Chris Parsons (1):
Updated status to show 'Not currently on any branch' in red
Christian Couder (1):
Documentation: rev-parse: add a few "--verify" and "--default" examples
Christian Stimming (3):
git-gui: Update German translation
gitk: Update German translation
gitk: German translation again updated
Dmitry Potapov (1):
git-init: autodetect core.ignorecase
Dustin Sallings (1):
Allow tracking branches to set up rebase by default.
Gerrit Pape (1):
gitk: Makefile/install: force permissions when installing files and dirs
Gustaf Hendeby (1):
Documentation: Add missing git svn commands
Heikki Orsila (1):
Add log.date config variable
Horst H. von Brand (1):
Fix recipient santitization
Imran M Yousuf (1):
Use '-f' option to point to the .gitmodules file
Jeff King (2):
send-email: specify content-type of --compose body
send-email: rfc2047-quote subject lines with non-ascii characters
Johannes Schindelin (2):
submodule update: add convenience option --init
pull --rebase: exit early when the working directory is dirty
Johannes Sixt (1):
git-gui: Report less precise object estimates for database compression
Lars Hjemli (1):
revision.c: really honor --first-parent
Marcel Koeppen (2):
Replace in-place sed in t7502-commit
Fix prepare-commit-msg hook and replace in-place sed
Michele Ballabio (1):
gitk: Disable "Reset %s branch to here" when on a detached head
Mike Ralphson (1):
Makefile: update the default build options for AIX
Miklos Vajna (2):
git-fast-import: rename cmd_*() functions to parse_*()
git-merge: exclude unnecessary options from OPTIONS_SPEC
Nicolas Pitre (9):
pack-objects: small cleanup
pack-objects: remove some double negative logic
pack-objects: simplify the condition associated with --all-progress
pack-objects: clean up write_object() a bit
pack-objects: move compression code in a separate function
pack-objects: allow for early delta deflating
pack-objects: fix early eviction for max depth delta objects
add a force_object_loose() function
let pack-objects do the writing of unreachable objects as loose objects
Paolo Bonzini (1):
add special "matching refs" refspec
Paul Mackerras (37):
gitk: Use git log without --topo-order and reorganize the commits
ourselves
gitk: Fix bug in assigning row numbers to arcs
gitk: Fix bug in parsing multiple revision arguments
gitk: Compute row numbers and order tokens lazily
gitk: Fix a couple of bugs
gitk: Fix more bugs resulting in Tcl "no such element in array" errors
gitk: More bug fixes and cleanups
gitk: Implement date mode in the new framework
gitk: Fix another collection of bugs
gitk: Don't try to show local changes from a head that isn't shown
gitk: Keep the same commits visible as other commits come in
gitk: Fix some corner cases in the targetid/targetrow stuff
gitk: Fix a couple of bugs in the find function
gitk: Fix potential bug with fake commit IDs in renumbervarc
gitk: Index [fnvr]highlights by id rather than row
gitk: Fix handling of flag arguments
gitk: Fix a bug in make_disporder
gitk: Select head of current branch by default
gitk: Select something appropriate on cherry-pick, branch reset and
checkout
gitk: Fix bug where editing an existing view would cause an infinite loop
gitk: Fix bug causing Tcl error when no commits are selected
gitk: Fix cherry-picking to insert a real row not a fake row
gitk: Cope better with getting commits that we have already seen
gitk: Fix bug where arcs could get lost
gitk: Handle updating with path limiting better
gitk: Fix problems with target row stuff
gitk: Don't filter view arguments through git rev-parse
gitk: Correct a few strings and comments to say "git log"
gitk: Fix some corner cases in computing vrowmod and displayorder
gitk: Avoid a crash in selectline if commitinfo($id) isn't set
gitk: Fix problem with target row not being in scroll region
gitk: Reorganize processing of arguments for git log
gitk: Fix handling of tree file list with special chars in names
gitk: Make updates go faster
gitk: Synchronize highlighting in file view for 'f' and 'b' commands
gitk: Show current row number and total number of rows
gitk: Add a progress bar for checking out a head
Peter Karlsson (1):
gitk: Initial Swedish translation.
Santiago Gala (1):
gitk: Spanish translation of gitk
Shawn O. Pearce (3):
git-gui: Don't use '$$cr master' with aspell earlier than 0.60
git-gui: Setup branch.remote,merge for shorthand git-pull
git-gui: Delete branches with 'git branch -D' to clear config
Steffen Prohaska (4):
t0050: Test autodetect core.ignorecase
t0050: Set core.ignorecase case to activate case insensitivity
t0050: Add test for case insensitive add
t0050: Fix merge test on case sensitive file systems
Stephen R. van den Berg (1):
Simplify and fix --first-parent implementation
Teemu Likonen (1):
Documentation/git-web--browse.txt: fix small typo
Thomas Arcila (1):
gitk: Allow users to view diffs in external diff viewer
Trent Piepho (1):
cvsexportcommit: Create config option for CVS dir
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-05-24 1:32 ` Junio C Hamano
@ 2008-05-30 20:43 ` Junio C Hamano
2008-06-02 8:01 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-05-30 20:43 UTC (permalink / raw)
To: git
[jc: I wrote this a few days ago but did not send it out]
* The 'master' branch has these since 1.5.6-rc0.
Christian Couder (1):
bisect: use "$GIT_DIR/BISECT_START" to check if we are bisecting
Dmitry V. Levin (1):
builtin-fetch.c (store_updated_refs): Honor update_local_ref() return
value
Gerrit Pape (2):
Documentation/git-bundle.txt: fix synopsis
commit --interactive: properly update the index before commiting
Jeff King (1):
clone: make sure we support the transport type
Johannes Schindelin (1):
hg-to-git: add --verbose option
Johannes Sixt (2):
t5700-clone-reference: Quote $U
Revert "filter-branch: subdirectory filter needs --full-history"
Junio C Hamano (19):
tests: do not use implicit "git diff --no-index"
diff-files: do not play --no-index games
"git diff": do not ignore index without --no-index
Update draft release notes for 1.5.6
log --graph: do not accept log --graphbogus
log --pretty: do not accept bogus "--prettyshort"
Release Notes for 1.5.5.2
Documentation/git.txt: link to 1.5.5.2 documentation.
Makefile: fix dependency on wt-status.h
show-branch --current: do not barf on detached HEAD
git-diff: allow --no-index semantics a bit more
git diff --no-index: default to page like other diff frontends
GIT 1.5.5.3
t5100: Avoid filename "nul"
Git::cat_blob: allow using an empty blob to fix git-svn breakage
fix sha1_pack_index_name()
Manual subsection to refer to other pages is SEE ALSO
Documentation: git-cherry uses git-patch-id
"git checkout -- paths..." should error out when paths cannot be written
Karl Hasselström (1):
Add some tests for git update-ref -d
Lea Wiemann (1):
gitweb: only display "next" links in logs if there is a next page
Michele Ballabio (1):
Documentation: fix graph in git-rev-parse.txt
Pieter de Bie (1):
builtin-fast-export: Only output a single parent per line
Shawn O. Pearce (5):
git-gui: Add a --trace command line option
git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
Don't diff empty tree on branch creation in paranoid update hook
Don't load missing ACL files in paranoid update hook
Ignore no-op changes in paranoid update hook
Twiinz (1):
git-gui: Vertically align textboxes with labels
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-05-30 20:43 ` Junio C Hamano
@ 2008-06-02 8:01 ` Junio C Hamano
2008-06-13 10:10 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-02 8:01 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement. I'll tag
-rc1 in a few days. Hopefully we can make this cycle much shorter than
the painfully long one we had for 1.5.5.
Adam Simpkins (2):
graph API: improve display of merge commits
graph API: avoid printing unnecessary padding before some octopus merges
Christian Couder (1):
Documentation: convert "glossary" and "core-tutorial" to man pages
Christian Engwer (1):
git-svn fails in prop_walk if $self->{path} is not empty
Jakub Narebski (1):
gitweb: Remove gitweb/test/ directory
Jamis Buck (1):
git-reset: honor -q and do not show progress message
John J. Franey (1):
Clarify description of <repository> argument to pull/fetch for naming
remotes.
Junio C Hamano (4):
checkout: make reset_clean_to_new() not die by itself
checkout: consolidate reset_{to_new,clean_to_new}()
unpack_trees(): allow callers to differentiate worktree errors from merge
errors
checkout: "best effort" checkout
Karl Hasselström (1):
Fix path duplication in git svn commit-diff
Lea Wiemann (4):
t/test-lib.sh: resolve symlinks in working directory, for pathname
comparisons
Git.pm: fix documentation of hash_object
glossary: improve a few links
Git.pm: fix return value of config method
Linus Torvalds (2):
Make pack creation always fsync() the result
Remove now unnecessary 'sync()' calls
Luciano Rocha (1):
git-init: accept --bare option
Marius Storm-Olsen (2):
Clearify the documentation for core.ignoreStat
Add shortcut in refresh_cache_ent() for marked entries.
Miklos Vajna (1):
Revision walking documentation: document most important functions
Nicolas Pitre (1):
make verify-pack a bit more useful with bad packs
Paolo Bonzini (1):
rollback lock files on more signals than just SIGINT
Seth Falcon (1):
Add a --dry-run option to git-svn rebase
Shawn O. Pearce (3):
Remove unused remote_prefix member in builtin-remote
Make "git-remote prune" delete refs according to fetch specs
Make "git-remote rm" delete refs acccording to fetch specs
Stephan Beyer (2):
Add test cases for git-am
Merge t4150-am-subdir.sh and t4151-am.sh into t4150-am.sh
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-02 8:01 ` Junio C Hamano
@ 2008-06-13 10:10 ` Junio C Hamano
2008-06-18 7:32 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-13 10:10 UTC (permalink / raw)
To: git
Since v1.5.6-rc2 there are handful more fixes. More important ones among
them are:
- "git-remote prune -n" fix (Olivier Marin)
- "git-log --graph --first-parent" fix (Adam Simpkins)
- "git-fast-export" fix for multi-root repository (Shawn)
- "gitk" works better with detached HEAD (Paul Mackerras)
Time for -rc3 this weekend and hopefully the final sometime next week.
---
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (1):
name-rev: Fix segmentation fault when using --all
Fred Maranhão (1):
fix typo in tutorial
Johannes Sixt (1):
Remove exec bit from builtin-fast-export.c
Junio C Hamano (1):
GIT 1.5.5.4
Lea Wiemann (1):
git-for-each-ref.txt: minor improvements
Michael Dressel (1):
describe: match pattern for lightweight tags too
Miklos Vajna (1):
git-read-tree: document -v option.
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Simpkins (2):
graph API: fix "git log --graph --first-parent"
git log --graph: print '*' for all commits, including merges
Alex Riesen (1):
Fix t5516 on cygwin: it does not like double slashes at the beginning of
a path
Ask Bjørn Hansen (2):
gitweb setup instruction: rewrite HEAD and root as well
send-email: Allow the envelope sender to be set via configuration
Boyd Lynn Gerber (2):
progress.c: avoid use of dynamic-sized array
Port to 12 other Platforms.
Chris Ridd (1):
Improve sed portability
Christian Couder (2):
documentation: convert "diffcore" and "repository-layout" to man pages
documentation: move git(7) to git(1)
Daniel Barkalow (1):
Use nonrelative paths instead of absolute paths for cloned repositories
Dirk Suesserott (1):
Documentation/git-mailsplit: Enhanced description of -o option
Geoffrey Irving (1):
doc: adding gitman.info and *.texi to .gitignore
Jakub Narebski (2):
gitweb: Fix "next" link on bottom of page
gitweb: Add charset info to "raw" output of 'text/plain' blobs
Jeff King (2):
Fix "git clone http://$URL" to check out the worktree when asked
document --pretty=tformat: option
Johannes Schindelin (1):
merge-recursive: respect core.autocrlf when writing out the result
Johannes Sixt (2):
rebase --interactive: Compute upstream SHA1 before switching branches
make_nonrelative_path: Use is_absolute_path()
Junio C Hamano (12):
commit: drop duplicated parents
GIT v1.5.6-rc1
t7502: do not globally unset GIT_COMMITTER_* environment variables
t7502: tighten loosely written test sequence
Documentation: git-log cannot use rev-list specific options
t7502: honor SHELL_PATH
GIT 1.5.6-rc2
http-push.c: remove duplicated code
"remote prune": be quiet when there is nothing to prune
Documentation/git-pull.txt: Use more standard [NOTE] markup
Documentation: exclude @pxref{[REMOTES]} from texinfo intermediate output
user-manual: describe how higher stages are set during a merge
Karl Hasselström (1):
Revert "git.el: Set process-environment instead of invoking env"
Kevin Ballard (1):
Documentation/git-filter-branch.txt: Fix description of --commit-filter
Lea Wiemann (5):
cat-file --batch: flush stdout also when objects are missing
t1006-cat-file.sh: typo
cat-file --batch / --batch-check: do not exit if hashes are missing
Documentation/git-cat-file.txt: add missing line break
t/.gitattributes: only ignore whitespace errors in test files
Linus Torvalds (1):
Consolidate SHA1 object file close
Marius Storm-Olsen (1):
Add testcase for merging in a CRLF repo
Mikael Magnusson (1):
Typo in RelNotes.
Miklos Vajna (3):
Strbuf documentation: document most functions
Remove unused code in parse_commit_buffer()
git-rebase -i: mention the short command aliases in the todo list
Olivier Marin (4):
remote show: fix the -n option
builtin-remote: split show_or_prune() in two separate functions
remote prune: print the list of pruned branches
remote show: list tracked remote branches with -n
Paul Mackerras (1):
gitk: Handle detached heads better
Philippe Bruhat (BooK) (1):
git-cvsimport: do not fail when CVSROOT is /
Pieter de Bie (1):
git-send-email: allow whitespace in addressee list
Shawn O. Pearce (1):
fast-export: Correctly generate initial commits with no parents
Stephan Beyer (6):
git-commit.txt: Correct option alternatives
git-commit.txt: Add missing long/short options
Docs: Use "-l::\n--long\n" format in OPTIONS sections
Docs: add some long/short options
git-describe.txt: document --always
git-name-rev.txt: document --no-undefined and --always
Teemu Likonen (1):
Print info about "git help COMMAND" on git's main usage pages
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-13 10:10 ` Junio C Hamano
@ 2008-06-18 7:32 ` Junio C Hamano
2008-06-18 10:59 ` Jeff King
2008-06-21 10:06 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-06-18 7:32 UTC (permalink / raw)
To: git
I am sending this out just as the final minute preview before 1.5.6 final,
hopefully tomorrow night.
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (1):
diff.c: fix emit_line() again not to add extra line
SZEDER Gábor (1):
diff: reset color before printing newline
* The 'master' branch has these since the last announcement
in addition to the above.
Alejandro Mery (1):
git-am: head -1 is obsolete and doesn't work on some new systems
Avery Pennarun (2):
git-svn: don't append extra newlines at the end of commit messages.
git-svn: test that extra blank lines aren't inserted in commit messages.
Christian Couder (2):
documentation: bisect: remove bits talking about a bisection branch
Documentation: RelNotes-1.5.6: talk about renamed HTML files
Flavio Poletti (1):
git-instaweb: improve auto-discovery of httpd and call conventions.
Jakub Narebski (2):
gitweb: Make it work with $GIT containing spaces
Use 'trash directory' thoroughly in t/test-lib.sh
Johan Herland (3):
cpio is no longer used by git-clone
Consistency: Use "libcurl" instead of "cURL library" and "curl"
The "curl" executable is no longer required
Junio C Hamano (8):
t4126: fix test that happened to work due to timing
sha1_file.c: dead code removal
GIT 1.5.6-rc3
Makefile: update check-docs target
Update RPM spec to drop curl executable requirement
create_tempfile: make sure that leading directories can be accessible by
peers
sha1_file.c: simplify parse_pack_index()
builtin-rerere: fix a small leak
Lea Wiemann (2):
gitweb: quote commands properly when calling the shell
gitweb: remove unused parse_ref method
Linus Torvalds (4):
Avoid cross-directory renames and linking on object creation
Make loose object file reading more careful
Simplify and rename find_sha1_file()
write_loose_object: don't bother trying to read an old object
Mark Levedahl (1):
git-submodule - Fix errors regarding resolve_relative_url
Mike Hommey (1):
Don't allocate too much memory in quote_ref_url
Miklos Vajna (2):
run-command documentation: fix "memset()" parameter
path-list documentation: document all functions and data structures
Olivier Marin (1):
Fix approxidate("never") to always return 0
Pierre Habouzit (1):
Make git reflog expire honour core.sharedRepository.
René Scharfe (1):
Ignore .gitattributes in bare repositories
SZEDER Gábor (2):
git add: add long equivalents of '-u' and '-f' options
completion: add more 'git add' options
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-06-18 7:32 ` Junio C Hamano
@ 2008-06-18 10:59 ` Jeff King
2008-06-21 10:06 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Jeff King @ 2008-06-18 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Jun 18, 2008 at 12:32:05AM -0700, Junio C Hamano wrote:
> I am sending this out just as the final minute preview before 1.5.6 final,
> hopefully tomorrow night.
I sent out a code cleanup for remote.c yesterday that fixes a segfault:
http://mid.gmane.org/20080616161502.GA7219@sigill.intra.peff.net
I am OK if it doesn't make it in to 1.5.6, but if not, then we should at
least apply the very safe one-liner that prevents the segfault. That
patch is below.
-- >8 --
fix segfault with "git push bogus:bogus"
We try to guess the type of the dst half of the refspec
based on the src half. If the src half is bogus, we ended up
dereferencing NULL.
---
remote.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index 91e3b11..fd8c71a 100644
--- a/remote.c
+++ b/remote.c
@@ -920,7 +920,8 @@ static int match_explicit(struct ref *src, struct ref *dst,
case 0:
if (!memcmp(dst_value, "refs/", 5))
matched_dst = make_linked_ref(dst_value, dst_tail);
- else if((dst_guess = guess_ref(dst_value, matched_src)))
+ else if(matched_src &&
+ (dst_guess = guess_ref(dst_value, matched_src)))
matched_dst = make_linked_ref(dst_guess, dst_tail);
else
error("unable to push to unqualified destination: %s\n"
--
1.5.6.rc3.160.g2a3c9
^ permalink raw reply related [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-18 7:32 ` Junio C Hamano
2008-06-18 10:59 ` Jeff King
@ 2008-06-21 10:06 ` Junio C Hamano
2008-06-23 7:25 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-21 10:06 UTC (permalink / raw)
To: git
* The 'maint' branch has now preparing for 1.5.6.1, with these noncritical
fixes.
Brandon Casey (2):
git-merge.sh: fix typo in usage message: sucesses --> succeeds
t7502-commit.sh: test_must_fail doesn't work with inline environment
variables
Dan McGee (1):
completion: add --graph to log command completion
Jan Krüger (1):
Documentation: fix formatting in git-svn
* The 'master' branch has these since the last announcement
in addition to the above. Not much to see here (yet).
Cristian Peraferrer (1):
Print errno upon failure to open the COMMIT_EDITMSG file
Jakub Narebski (1):
t/README: Add 'Skipping Tests' section below 'Running Tests'
Lea Wiemann (1):
test-lib.sh: add --long-tests option
Lukas Sandström (1):
Add a helper script to send patches with Mozilla Thunderbird
Shawn O. Pearce (1):
Correct documentation for git-push --mirror
Teemu Likonen (2):
bash: Add more option completions for 'git log'
Add target "install-html" the the top level Makefile
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-21 10:06 ` Junio C Hamano
@ 2008-06-23 7:25 ` Junio C Hamano
2008-06-25 9:34 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-23 7:25 UTC (permalink / raw)
To: git
There are a few more fixes destined for maint, being tested in next first.
* The 'maint' branch has these fixes since the last announcement.
Michele Ballabio (1):
parse-options.c: fix documentation syntax of optional arguments
Stephan Beyer (3):
api-builtin.txt: update and fix typo
api-parse-options.txt: Introduce documentation for parse options API
Extend parse-options test suite
* The 'master' branch has these since the last announcement
in addition to the above.
Jakub Narebski (2):
gitweb: Separate filling list of projects info
gitweb: Separate generating 'sort by' table header
Jeff King (5):
fix whitespace violations in test scripts
mask necessary whitespace policy violations in test scripts
avoid whitespace on empty line in automatic usage message
avoid trailing whitespace in zero-change diffstat lines
enable whitespace checking of test scripts
Junio C Hamano (1):
diff -c/--cc: do not include uninteresting deletion before leading
context
Karl Hasselström (2):
Clean up builtin-update-ref's option parsing
Make old sha1 optional with git update-ref -d
Linus Torvalds (3):
racy-git: an empty blob has a fixed object name
Make git_dir a path relative to work_tree in setup_work_tree()
Shrink the git binary a bit by avoiding unnecessary inline functions
Marius Storm-Olsen (3):
Add an optional <mode> argument to commit/status -u|--untracked-files
option
Add argument 'no' commit/status option -u|--untracked-files
Add configuration option for default untracked files mode
Nanako Shiraishi (2):
environment.c: remove unused function
config.c: make git_env_bool() static
Pieter de Bie (1):
builtin-fast-export: Add importing and exporting of revision marks
Rafael Garcia-Suarez (1):
gitweb: remove git_blame and rename git_blame2 to git_blame
René Scharfe (1):
Teach new attribute 'export-ignore' to git-archive
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-23 7:25 ` Junio C Hamano
@ 2008-06-25 9:34 ` Junio C Hamano
2008-07-02 6:28 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-06-25 9:34 UTC (permalink / raw)
To: git
We'd need a maint release soon to push out the mkstemp() breakage but not
tonight. There are a handful changes that are in 'master' and 'next' that
need backport/backmerge before 1.5.6.1 happens.
* The 'maint' branch has these fixes since the last announcement.
Jan Krüger (1):
git-svn: make rebuild respect rewriteRoot option
Patrick Higgins (1):
Workaround for AIX mkstemp()
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (1):
clone: create intermediate directories of destination repo
Junio C Hamano (2):
pre-rebase hook update
Ship sample hooks with .sample suffix
Michele Ballabio (1):
t9301-fast-export.sh: Remove debug line
Nicolas Pitre (8):
call init_pack_revindex() lazily
implement some resilience against pack corruptions
test case for pack resilience against corruptions
refactor pack structure allocation
optimize verify-pack a bit
move show_pack_info() where it belongs
verify-pack: check packed object CRC when using index version 2
verify-pack: test for detection of index v2 object CRC mismatch
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-06-25 9:34 ` Junio C Hamano
@ 2008-07-02 6:28 ` Junio C Hamano
2008-07-06 10:04 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-02 6:28 UTC (permalink / raw)
To: git
There are a few fixes on 'maint', in addition to futureproofing of "git
shell" so that eventually we can update the ssh clients to ask for server
side programs using "git upload-pack" syntax without a dash between "git"
and the subcommand name.
Many of the medimu size items for 1.6.0 have been merged to 'master'. The
port to MinGW series will also be merged shortly.
----------------------------------------------------------------
GIT v1.6.0 Release Notes (draft)
================================
User visible changes
--------------------
With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.
Updates since v1.5.6
--------------------
(subsystems)
* git-p4 in contrib learned "allowSubmit" configuration to control on
which branch to allow "submit" subcommand.
(portability)
* Sample hook scripts shipped in templates/ are now suffixed with
*.sample. We used to prevent them from triggering by default by
relying on the fact that we install them as unexecutable, but on
some filesystems this approach does not work. Instead of running
"chmod +x" on them, the users who want to activate these samples
as-is can now rename them dropping *.sample suffix.
* perl's in-place edit (-i) does not work well without backup files on Windows;
some tests are rewritten to cope with this.
(documentation)
* Updated howto/update-hook-example
* Got rid of usage of "git-foo" from the tutorial.
* Disambiguating "--" between revs and paths is finally documented.
(performance, robustness, sanity etc.)
* even more documentation pages are now accessible via "man" and "git help".
* reduced excessive inlining to shrink size of the "git" binary.
* verify-pack checks the object CRC when using version 2 idx files.
* When an object is corrupt in a pack, the object became unusable even
when the same object is available in a loose form, We now try harder to
fall back to these redundant objects when able. In particular, "git
repack -a -f" can be used to fix such a corruption as long as necessary
objects are available.
* git-clone does not create refs in loose form anymore (it behaves as
if you immediately ran git-pack-refs after cloning). This will help
repositories with insanely large number of refs.
* core.fsyncobjectfiles configuration can be used to ensure that the loose
objects created will be fsync'ed (this is only useful on filesystems
that does not order data writes properly).
* "git commit-tree" plumbing can make Octopus with more than 16 parents.
"git commit" has been capable of this for quite some time.
(usability, bells and whistles)
* git-apply can handle a patch that touches the same path more than once
much better than before.
* git-apply can be told not to trust the line counts recorded in the input
patch but recount, with the new --recount option.
* git-archive can be told to omit certain paths from its output using
export-ignore attributes.
* git-clone can clone from a remote whose URL would be rewritten by
configuration stored in $HOME/.gitconfig now.
* git-diff --check now checks leftover merge conflict markers.
* When remote side used to have branch 'foo' and git-fetch finds that now
it has branch 'foo/bar', it refuses to lose the existing remote tracking
branch and its reflog. The error message has been improved to suggest
pruning the remote if the user wants to proceed and get the latest set
of branches from the remote, including such 'foo/bar'.
* fast-export learned to export and import marks file; this can be used to
interface with fast-import incrementally.
* Original SHA-1 value for "update-ref -d" is optional now.
* git-send-mail can talk not just over SSL but over TLS now.
* You can tell "git status -u" to even more aggressively omit checking
untracked files with --untracked-files=no.
* Error codes from gitweb are made more descriptive where possible, rather
than "403 forbidden" as we used to issue everywhere.
(internal)
Fixes since v1.5.6
------------------
All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.
* diff -c/--cc showed unnecessary "deletion" lines at the context
boundary (needs backmerge to maint).
* "git-clone <src> <dst>" did not create leading directories for <dst>
like the scripted version used to do (needs backport to maint).
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.6.1.
Avery Pennarun (1):
git-svn: avoid filling up the disk with temp files.
Björn Steinbrink (1):
git cat-file: Fix memory leak in batch mode
Eric Wong (1):
git-svn: don't sanitize remote names in config
Jeff King (1):
doc/rev-parse: clarify reflog vs --until for specifying revisions
Jochen Voss (1):
avoid off-by-one error in run_upload_archive
Joey Hess (1):
fix git config example syntax
Junio C Hamano (5):
diff --check: do not discard error status upon seeing a good line
git-shell: accept "git foo" form
GIT 1.5.4.6
GIT 1.5.5.5
Start draft release notes for 1.5.6.2
Thomas Rast (1):
Fix 'git show' on signed tag of signed tag of commit
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix use of "perl -i" on Windows
Brian Gernhardt (2):
Fix t4017-diff-retval for white-space from wc
Add test results directory to t/.gitignore
Christian Couder (1):
help: check early if we have a command, if not try a documentation topic
Dmitry Potapov (2):
update-hook-example: optionally allow non-fast-forward
shrink git-shell by avoiding redundant dependencies
Don Zickus (1):
git-apply: handle a patch that touches the same path more than once
better
Jeff King (3):
improve for-each-ref test script
fetch: report local storage errors in status table
fetch: give a hint to the user when local refs fail to update
Jing Xue (1):
Add 'git-p4.allowSubmit' to git-p4
Johan Herland (4):
Incorporate fetched packs in future object traversal
Move pack_refs() and friends into libgit
Prepare testsuite for a "git clone" that packs refs
Teach "git clone" to pack refs
Johannes Schindelin (4):
clone: respect url.insteadOf setting in global configs
commit-tree: lift completely arbitrary limit of 16 parents
Allow git-apply to recount the lines in a hunk (AKA recountdiff)
clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
Jonathan Nieder (7):
Documentation: fix links to tutorials and other new manual pages
whitespace fix in Documentation/git-repack.txt
Documentation: complicate example of "man git-command"
git-daemon(1): don't assume git-daemon is in /usr/bin
Documentation: prepare to be consistent about "git-" versus "git "
Documentation: be consistent about "git-" versus "git "
Documentation formatting and cleanup
Junio C Hamano (15):
git-shell: accept "git foo" form
Prepare execv_git_cmd() for removal of builtins from the filesystem
Keep some git-* programs in $(bindir)
Allow "git-reset path" when unambiguous
Start draft release notes for 1.6.0
diff --check: explain why we do not care whether old side is binary
check_and_emit_line(): rename and refactor
checkdiff: pass diff_options to the callback
Teach "diff --check" about new blank lines at end
diff --check: detect leftover conflict markers
Update sample pre-commit hook to use "diff --check"
Document the double-dash "rev -- path" disambiguator
t9700: skip when Test::More is not available
Update draft release notes for 1.6.0
Update draft release notes for 1.6.0
Kevin Ballard (1):
git-send-email: Accept fifos as well as files
Lea Wiemann (5):
t/test-lib.sh: add test_external and test_external_without_stderr
Git.pm: add test suite
gitweb: standarize HTTP status codes
test-lib.sh: show git init output when in verbose mode
GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy
Linus Torvalds (4):
Split up default "core" config parsing into helper routine
Split up default "user" config parsing into helper routine
Split up default "i18n" and "branch" config parsing into helper routines
Add config option to enable 'fsync()' of object files
Miklos Vajna (1):
A simple script to parse the results from the testcases
Nanako Shiraishi (1):
gitcli: Document meaning of --cached and --index
Nguyễn Thái Ngọc Duy (1):
Move all dashed-form commands to libexecdir
Nicolas Pitre (2):
repack.usedeltabaseoffset config option now defaults to "true"
pack.indexversion config option now defaults to 2
Olivier Marin (2):
Documentation: remove {show,whatchanged}.difftree config options
show_stats(): fix stats width calculation
Patrick Higgins (1):
Remove the use of '--' in merge program invocation
Stephan Beyer (2):
api-builtin.txt: update and fix typo
t3404: stricter tests for git-rebase--interactive
Sverre Rabbelier (2):
Modify test-lib.sh to output stats to t/test-results/*
Hook up the result aggregation in the test makefile.
Ted Percival (1):
Don't use dash commands (git-foo) in tutorial-2
Thomas Rast (2):
git-send-email: add support for TLS via Net::SMTP::SSL
git-send-email: prevent undefined variable warnings if no encryption is
set
jrnieder@uchicago.edu (1):
Documentation: don't assume git-sh-setup and git-parse-remote are in PATH
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-07-02 6:28 ` Junio C Hamano
@ 2008-07-06 10:04 ` Junio C Hamano
2008-07-08 2:46 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw)
To: git
With accumulated fixes, the latest maintenance release 1.5.6.2 is out.
On the 'master' front, port to MinGW has now been merged, and the next
major release 1.6.0 is already taking shape.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to what is in maint.
Adam Brewster (1):
Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
Brian Gernhardt (1):
Documentation: Point to gitcli(7) from git(1)
Brian Hetro (5):
builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and
'format.suffix'
convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
diff.c: Use 'git_config_string' to get 'diff.external'
http.c: Use 'git_config_string' to clean up SSL config.
builtin-commit.c: Use 'git_config_string' to get 'commit.template'
Christian Couder (2):
Fix "config_error_nonbool" used with value instead of key
Fix "config_error_nonbool" used with value instead of key
Johannes Schindelin (2):
Windows: always chmod(, 0666) before unlink().
git fetch-pack: do not complain about "no common commits" in an empty
repo
Johannes Sixt (35):
Add compat/regex.[ch] and compat/fnmatch.[ch].
Compile some programs only conditionally.
Add target architecture MinGW.
Windows: Use the Windows style PATH separator ';'.
setup.c: Prepare for Windows directory separators.
Windows: Treat Windows style path names.
Windows: Handle absolute paths in safe_create_leading_directories().
Windows: Strip ".exe" from the program name.
Windows: Implement a wrapper of the open() function.
Windows: A minimal implemention of getpwuid().
Windows: Work around misbehaved rename().
Make my_mktime() public and rename it to tm_to_time_t()
Windows: Implement gettimeofday().
Windows: Fix PRIuMAX definition.
Windows: Implement setitimer() and sigaction().
Windows: Wrap execve so that shell scripts can be invoked.
Windows: A pipe() replacement whose ends are not inherited to children.
Windows: Implement start_command().
Windows: A rudimentary poll() emulation.
Windows: Disambiguate DOS style paths from SSH URLs.
Windows: Implement asynchronous functions as threads.
Windows: Work around incompatible sort and find.
Windows: Implement wrappers for gethostbyname(), socket(), and connect().
Windows: Implement a custom spawnve().
Windows: Add a custom implementation for utime().
Windows: Use a customized struct stat that also has the st_blocks member.
Turn builtin_exec_path into a function.
Windows: Compute the fallback for exec_path from the program invocation.
Windows: Use a relative default template_dir and ETC_GITCONFIG
When installing, be prepared that template_dir may be relative.
Windows: Make the pager work.
Windows: Work around an oddity when a pipe with no reader is written to.
Windows: Make 'git help -a' work.
Windows: TMP and TEMP environment variables specify a temporary
directory.
t4127-apply-same-fn: Avoid sed -i
Jonathan Nieder (15):
git-format-patch(1): fix stray \ in output
Documentation: fix gitlinks
manpages: fix bogus whitespace
git(1): add comma
git-commit(1): depersonalize description
Documentation: rewrap to prepare for "git-" vs "git " change
Documentation: more "git-" versus "git " changes
gitdiffcore(7): fix awkward wording
manpages: italicize command names in synopses
manpages: italicize command names
manpages: italicize git command names (which were in teletype font)
manpages: italicize gitk's name (where it was in teletype font)
manpages: italicize nongit command names (if they are in teletype font)
manpages: italicize git subcommand names (which were in teletype font)
manpages: use teletype font for sample command lines
Junio C Hamano (3):
fast-export --export-marks: fix off by one error
attribute documentation: keep EXAMPLE at end
clone -q: honor "quiet" option over native transports.
Marius Storm-Olsen (1):
Windows: Add a new lstat and fstat implementation based on Win32 API.
Matthew Ogilvie (1):
Documentation cvs: Clarify when a bare repository is needed
Miklos Vajna (6):
Retire 'stupid' merge strategy
INSTALL: Update section about git-frotz form.
hg-to-git: avoid raising a string exception
hg-to-git: abort if the project directory is not a hg repo
hg-to-git: rewrite "git-frotz" to "git frotz"
hg-to-git: use git init instead of git init-db
Nikolaus Schulz (1):
Documentation: be precise about which date --pretty uses
Ramsay Allan Jones (1):
Fix some warnings (on cygwin) to allow -Werror
Steffen Prohaska (2):
Windows: Fix ntohl() related warnings about printf formatting
compat/pread.c: Add a forward declaration to fix a warning
Thomas Rast (2):
git-send-email: Do not attempt to STARTTLS more than once
Fix apply --recount handling of no-EOL line
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-07-06 10:04 ` Junio C Hamano
@ 2008-07-08 2:46 ` Junio C Hamano
2008-07-14 5:33 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-08 2:46 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since 1.5.6.2.
Alex Riesen (1):
git-clone: remove leftover debugging fprintf().
Brian Hetro (5):
builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and
'format.suffix'
convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
diff.c: Use 'git_config_string' to get 'diff.external'
http.c: Use 'git_config_string' to clean up SSL config.
builtin-commit.c: Use 'git_config_string' to get 'commit.template'
Christian Couder (1):
Fix "config_error_nonbool" used with value instead of key
Gerrit Pape (1):
git-svn.perl: workaround assertions in svn library 1.5.0
Junio C Hamano (3):
attribute documentation: keep EXAMPLE at end
clone -q: honor "quiet" option over native transports.
mailinfo: feed the correct line length to decode_transfer_encoding()
Matthew Ogilvie (1):
Documentation cvs: Clarify when a bare repository is needed
Mikael Magnusson (1):
Fix grammar in git-rev-parse(1).
Nikolaus Schulz (1):
Documentation: be precise about which date --pretty uses
* The 'master' branch has these since the last announcement
in addition to the above.
Abhijit Menon-Sen (2):
git-gui: Move on to the next filename after staging/unstaging a change
git-gui: Don't select the wrong file if the last listed file is staged.
Daniel Barkalow (1):
Only use GIT_CONFIG in "git config", not other programs
David Reiss (4):
Implement normalize_absolute_path
Fold test-absolute-path into test-path-utils
Add support for GIT_CEILING_DIRECTORIES
Eliminate an unnecessary chdir("..")
Dmitry Potapov (1):
completion.bash: add 'skip' and 'run' to git-bisect
Jakub Narebski (1):
gitweb: Describe projects_index format in more detail
Johannes Schindelin (3):
Add another fast-import example, this time for .zip files
git daemon: avoid calling syslog() from a signal handler
run_command(): respect GIT_TRACE
Johannes Sixt (1):
git-gui: Implement "Stage/Unstage Line"
Junio C Hamano (6):
rerere: rerere_created_at() and has_resolution() abstraction
git-rerere: detect unparsable conflicts
rerere: remove dubious "tail_optimization"
t4200: fix rerere test
rerere.autoupdate
Update draft release notes for 1.6.0
Richard Quirk (1):
git-gui: Fix accidental staged state toggle when clicking top pixel row
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-07-08 2:46 ` Junio C Hamano
@ 2008-07-14 5:33 ` Junio C Hamano
2008-07-16 3:33 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-14 5:33 UTC (permalink / raw)
To: git
* The 'maint' branch is at 1.5.6.3
* The 'master' branch has these since the last announcement
in addition to what's in 1.5.6.3
Abhijit Menon-Sen (2):
Implement "git stash branch <newbranch> <stash>"
Add a test for "git stash branch"
Adam Brewster (1):
Teach git-bundle to read revision arguments from stdin like git-rev-list.
Brandon Casey (1):
t7701-repack-unpack-unreachable.sh: check timestamp of unpacked objects
Eric Hanchrow (2):
user-manual: typo and grammar fixes
Documentation: fix broken "linkgit" links
Eric Raible (2):
Documentation: tweak use case in "git stash save --keep-index"
completion: add branch options --contains --merged --no-merged
Jeff King (2):
Allow per-command pager config
avoid null SHA1 in oldest reflog
Johannes Schindelin (2):
Teach "git apply" to prepend a prefix with "--root=<root>"
Allow cherry-picking root commits
Johannes Sixt (1):
Provide fallback definitions of PRIu32 and PRIx32
Junio C Hamano (17):
revision traversal: --children option
rev-list --children
builtin-blame.c: move prepare_final() into a separate function.
builtin-blame.c: allow more than 16 parents
git-blame --reverse
Per-ref reflog expiry configuration
Make default expiration period of reflog used for stash infinite
apply --root: thinkofix.
Refactor "tracking statistics" code used by "git checkout"
git-status: show the remote tracking statistics
git-branch -v: show the remote tracking statistics
stat_tracking_info(): clear object flags used during counting
branch -r -v: do not spit out garbage
git-apply --directory: make --root more similar to GNU diff
Tone down warning about GNU Interactive Tools
Documentation: update sections on naming revisions and revision ranges
apply: fix copy/rename breakage
Mark Levedahl (1):
install-doc-quick - use git --exec-path to find git-sh-setup
Mike Hommey (4):
Catch failures from t5540-http-push
Fix http-push test
Skip t5540-http-push test when USE_CURL_MULTI is undefined
Avoid apache complaining about lack of server's FQDN
Petr Baudis (1):
Git.pm: Add remote_refs() git-ls-remote frontend
Pierre Habouzit (12):
parse-opt: have parse_options_{start,end}.
parse-opt: Export a non NORETURN usage dumper.
parse-opt: create parse_options_step.
parse-opt: do not print errors on unknown options, return -2 intead.
parse-opt: fake short strings for callers to believe in.
parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
revisions: split handle_revision_opt() from setup_revisions()
git-blame: migrate to incremental parse-option [1/2]
git-blame: migrate to incremental parse-option [2/2]
git-blame: fix lapsus
git-shortlog: migrate to parse-options partially.
revisions: refactor handle_revision_opt into parse_revision_opt.
Ramsay Allan Jones (3):
t9113-*.sh: provide user feedback when test skipped
t9100-git-svn-basic.sh: Fix determination of utf-8 locale
git-request-pull: replace call to deprecated peek-remote
Robert Shearman (1):
git-send-email: Fix authenticating on some servers when using TLS.
SZEDER Gábor (1):
stash: introduce 'stash save --keep-index' option
Shawn O. Pearce (3):
Correct pack memory leak causing git gc to try to exceed ulimit
bash completion: Improve responsiveness of git-log completion
bash completion: Don't offer "a.." as a completion for "a."
Stephan Beyer (3):
git-am/git-mailsplit: correct synopsis for reading from stdin
t3404: test two "preserve merges with -p" cases
Make rebase--interactive use OPTIONS_SPEC
Thomas Rast (3):
git-add--interactive: replace hunk recounting with apply --recount
git-add--interactive: remove hunk coalescing
git-add--interactive: manual hunk editing mode
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-07-14 5:33 ` Junio C Hamano
@ 2008-07-16 3:33 ` Junio C Hamano
2008-07-20 1:59 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-16 3:33 UTC (permalink / raw)
To: git
"Merge-in-C" is in, so is "rename .dotest", and remaining Windows bits.
Now it is almost there for 1.6.0-rc0.
* The 'master' branch has these since the last announcement.
Alexander N. Gavrilov (1):
Fix quadratic performance in rewrite_one.
Brian Gernhardt (1):
Documentation: mention ORIG_HEAD in am, merge, and rebase
Ciaran McCreesh (1):
Make git-add -i accept ranges like 7-
Dmitry Kakurin (1):
Fixed text file auto-detection: treat EOF character 032 at the end of
file as printable
Frederik Schwarzer (1):
git-svn: typofix
Ian Katz (1):
tutorial: use prompt with user names in example, to clarify who is doing
what
Johannes Schindelin (6):
Convert CR/LF to LF in tag signatures
Add pretty format %aN which gives the author name, respecting .mailmap
Move MERGE_RR from .git/rr-cache/ into .git/
git-gui: MERGE_RR lives in .git/ directly with newer Git versions
shortlog: support --pretty=format: option
Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
João Abecasis (1):
git-svn: find-rev and rebase for SVN::Mirror repositories
Junio C Hamano (10):
Introduce get_merge_bases_many()
Introduce reduce_heads()
Teach "am" and "rebase" to mark the original position with ORIG_HEAD
branch --contains: default to HEAD
branch --merged/--no-merged: allow specifying arbitrary commit
Teach merge.log to "git-merge" again
Update draft release notes for 1.6.0
reduce_heads(): protect from duplicate input
tutorial: clarify "pull" is "fetch + merge"
Update draft release notes to 1.6.0
Lukas Sandström (1):
git-mailinfo: Fix getting the subject from the in-body [PATCH] line
Mark Levedahl (2):
git-submodule - make "submodule add" more strict, and document it
git-submodule - register submodule URL if adding in place
Mike Pape (1):
We need to check for msys as well as Windows in add--interactive.
Miklos Vajna (15):
Move split_cmdline() to alias.c
Move commit_list_count() to commit.c
Move parse-options's skip_prefix() to git-compat-util.h
Add new test to ensure git-merge handles pull.twohead and pull.octopus
Move read_cache_unmerged() to read-cache.c
git-fmt-merge-msg: make it usable from other builtins
Introduce get_octopus_merge_bases() in commit.c
Add new test to ensure git-merge handles more than 25 refs.
Add new test case to ensure git-merge reduces octopus parents when
possible
Add new test case to ensure git-merge prepends the custom merge message
git-commit-tree: make it usable from other builtins
Fix t7601-merge-pull-config.sh on AIX
Build in merge
t6021: add a new test for git-merge-resolve
Add a new test for git-merge-resolve
Nicolas Pitre (1):
restore legacy behavior for read_sha1_file()
Olivier Marin (1):
builtin-rerere: more carefully find conflict markers
Pavel Roskin (1):
t9600: allow testing with cvsps 2.2, including beta versions
Pierre Habouzit (1):
parse-options: add PARSE_OPT_LASTARG_DEFAULT flag
Shawn O. Pearce (3):
bash completion: Append space after file names have been completed
bash completion: Resolve git show ref:path<tab> losing ref: portion
bash completion: Remove dashed command completion support
Soeren Finster (1):
git-gui: Exit shortcut in MacOSX repaired
Steffen Prohaska (3):
Move code interpreting path relative to exec-dir to new function
system_path()
help.c: Add support for htmldir relative to git_exec_path()
help (Windows): Display HTML in default browser using Windows' shell API
Stephan Beyer (1):
rerere: Separate libgit and builtin functions
Sverre Hvammen Johansen (1):
reduce_heads(): thinkofix
Teemu Likonen (1):
bash: Add long option completion for 'git send-email'
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-07-16 3:33 ` Junio C Hamano
@ 2008-07-20 1:59 ` Junio C Hamano
2008-07-20 11:20 ` Lars Noschinski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-07-20 1:59 UTC (permalink / raw)
To: git
* The 'maint' branch is at 1.5.6.4.
* The 'master' branch has these since the last announcement
in addition to what is already in 1.5.6.4.
Alexander Gavrilov (3):
Avoid rescanning unchanged entries in search for copies.
Do not try to detect move/copy for entries below threshold.
Support gitlinks in fast-import.
Eric Raible (1):
Teach lookup_prog not to select directories
Eric Wong (1):
t/lib-git-svn: fix SVN_HTTPD tests to work with "trash directory"
Fabian Emmes (2):
Testsuite: Unset CVS_SERVER
testsuite for cvs co -c
Johannes Sixt (1):
builtin-clone: rewrite guess_dir_name()
Junio C Hamano (9):
git-rebase: report checkout failure
t/aggregate-results: whitespace fix
Update draft release notes for 1.6.0
read-cache.c: typofix
mailinfo: off-by-one fix for [PATCH (foobar)] removal from Subject: line
builtin-remote.c: fix earlier "skip_prefix()" conversion
t9001 (send-email): Do not use hardcoded /bin/sh in test
.mailmap update
Getting closer to 1.6.0-rc0
Lars Noschinski (2):
cvsserver: Add support for packed refs
cvsserver: Add cvs co -c support
Lukas Sandström (3):
Make some strbuf_*() struct strbuf arguments const.
Add some useful functions for strbuf manipulation.
git-mailinfo: use strbuf's instead of fixed buffers
Miklos Vajna (4):
t0001-init.sh: change confusing directory name
t1007-hash-object.sh: use quotes for the test description
git-bisect: use dash-less form on git bisect log
make remove-dashes: apply to scripts and programs as well, not just to
builtins
Nanako Shiraishi (3):
cache-tree.c: make cache_tree_find() static
builtin-describe.c: make a global variable "pattern" static
parse-options.c: make check_typos() static
Peter Harris (1):
Add ANSI control code emulation for the Windows console
Petr Baudis (5):
Documentation/git-submodule.txt: Add Description section
Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
Documentation/git-submodule.txt: Further clarify the description
Documentation: How to ignore local changes in tracked files
Documentation/git-merge.txt: Partial rewrite of How Merge Works
René Scharfe (8):
archive: remove args member from struct archiver
add context pointer to read_tree_recursive()
archive: add baselen member to struct archiver_args
archive: centralize archive entry writing
archive: unify file attribute handling
archive: remove extra arguments parsing code
archive: make zip compression level independent from core git
archive: remove unused headers
Stephan Beyer (4):
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
t/: Use "test_must_fail git" instead of "! git"
Make usage strings dash-less
Link git-shell only to a subset of libgit.a
SungHyun Nam (1):
t/Makefile: use specified shell when running aggregation script
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-07-20 1:59 ` Junio C Hamano
@ 2008-07-20 11:20 ` Lars Noschinski
2008-07-20 18:27 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Lars Noschinski @ 2008-07-20 11:20 UTC (permalink / raw)
To: git
* Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>Lars Noschinski (2):
> cvsserver: Add support for packed refs
> cvsserver: Add cvs co -c support
Any specific reason why you did not merge the test for packed refs
support? Was it considered superfluous?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-07-20 11:20 ` Lars Noschinski
@ 2008-07-20 18:27 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
Lars Noschinski <lars-2008-1@usenet.noschinski.de> writes:
> * Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>>Lars Noschinski (2):
>> cvsserver: Add support for packed refs
>> cvsserver: Add cvs co -c support
>
> Any specific reason why you did not merge the test for packed refs
> support? Was it considered superfluous?
No, it was not even considered. This phenomenon is called "lost in the
noise" ;-)
Thanks for reminding. Applied.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable frozen)
@ 2008-01-30 8:32 Junio C Hamano
2008-02-12 7:25 ` What's in git.git Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-01-30 8:32 UTC (permalink / raw)
To: git
There shouldn't be anything eye-popping. Hopefully we can do
the final soonish, perhaps this weekend.
I may have made small touch-ups to a few commits, so please
check them over.
Thanks.
* The 'master' branch has these since v1.5.4-rc5
Brandon Casey (1):
git-relink: avoid hard linking in objects/info directory
Bruno Ribas (1):
gitweb: Make use of the $git_dir variable at sub
git_get_project_description
Christian Couder (3):
Documentation: config: add "browser.<tool>.path".
Documentation: help: specify supported html browsers.
instaweb: use 'browser.<tool>.path' config option if it's set.
Jakub Narebski (1):
gitweb: Add info about $projectroot and $projects_list to gitweb/README
Jeff King (1):
t9001: add missing && operators
Jim Meyering (1):
fix doc typos
Johannes Schindelin (1):
Add test for rebase -i with commits that do not pass pre-commit
Junio C Hamano (1):
reflog-expire: Avoid creating new files in a directory inside readdir(3)
loop
Yasushi SHOJI (1):
gitweb: Convert generated contents to utf8 in commitdiff_plain
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git
2008-01-30 8:32 What's in git.git (stable frozen) Junio C Hamano
@ 2008-02-12 7:25 ` Junio C Hamano
2008-02-17 3:56 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-12 7:25 UTC (permalink / raw)
To: git
Config parser fixes are in 'maint', along with many other
minor fixes.
As promised, a handful topics that have been cooking in 'next'
have graduated to 'master'.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.4.1
David Steven Tweed (1):
Make git prune remove temporary packs that look like write failures
Frank Lichtenheld (1):
config: Fix --unset for continuation lines
Gerrit Pape (1):
builtin-commit: remove .git/SQUASH_MSG upon successful commit
James Bowes (1):
Add a BuildRequires for gettext in the spec file.
Johannes Schindelin (2):
bisect: allow starting with a detached HEAD
Document that the default of branch.autosetupmerge is true
Jonas Fonseca (1):
man pages are littered with .ft C and others
Junio C Hamano (24):
git-pull documentation: fix markup
archive-tar.c: guard config parser from value=NULL
Add config_error_nonbool() helper function
builtin-apply.c: guard config parser from value=NULL
builtin-branch.c: guard config parser from value=NULL
builtin-commit.c: guard config parser from value=NULL
builtin-config.c: guard config parser from value=NULL
builtin-log.c: guard config parser from value=NULL
builtin-reflog.c: guard config parser from value=NULL
builtin-show-branch.c: guard config parser from value=NULL
builtin-tag.c: guard config parser from value=NULL
connect.c: guard config parser from value=NULL
convert.c: guard config parser from value=NULL
diff.c: guard config parser from value=NULL
git.c: guard config parser from value=NULL
help.c: guard config parser from value=NULL
http.c: guard config parser from value=NULL
merge-recursive.c: guard config parser from value=NULL
remote.c: guard config parser from value=NULL
setup.c: guard config parser from value=NULL
wt-status.c: guard config parser from value=NULL
imap-send.c: guard config parser from value=NULL
builtin-log.c: guard config parser from value=NULL
config.c: guard config parser from value=NULL
Martin Koegler (1):
pack-objects: only throw away data during memory pressure
Mike Hommey (1):
Work around curl-gnutls not liking to be reinitialized
Miklos Vajna (1):
builtin-gc.c: guard config parser from value=NULL
Uwe Kleine-König (1):
rebase -i: accept -m as advertised in the man page
* The 'master' branch has these since v1.5.4 in addition to the
above.
Alexandre Julliard (4):
git.el: Support for showing unknown/ignored directories.
git.el: Added a command to amend a commit.
git.el: Check for existing buffers on revert.
git.el: Better handling of subprocess errors.
Bruno Ribas (1):
gitweb: Make use of the $git_dir variable at sub git_get_project_url_list
Christian Couder (1):
config: add test cases for empty value and no value config variables.
Daniel Barkalow (2):
Test :/string form for checkout
Reduce the number of connects when fetching
David Brown (1):
git-send-email: Generalize auto-cc recipient mechanism.
Eric Wong (1):
git-svn: improve repository URL matching when following parents
Florian La Roche (1):
gitweb: Make feed entries point to commitdiff view
James Bowes (1):
Add a BuildRequires for gettext in the spec file.
Jason McMullan (1):
Remove $Id: ..$ $Header: ..$ etc from +ko and +k files during import
Johannes Schindelin (3):
Also use unpack_trees() in do_diff_cache()
Fix "git clone" for git:// protocol
Introduce the config variable pack.packSizeLimit
Johannes Sixt (1):
Fix misuse of prefix_path()
Jonas Fonseca (1):
man pages are littered with .ft C and others
Junichi Uekawa (1):
git-blame.el: show the when, who and what in the minibuffer.
Junio C Hamano (12):
index: be careful when handling long names
Avoid running lstat(2) on the same cache entry.
read-cache.c: fix a couple more CE_REMOVE conversion
read-cache.c: introduce is_racy_timestamp() helper
lazy index hashing
Sane use of test_expect_failure
test: reword the final message of tests with known breakages
known breakage: revision range computation with clock skew
fix misuse of prefix_path()
Make error messages from cherry-pick/revert more sensible
Define the project whitespace policy
Update the main documentation (stale notes section)
Karl Hasselström (2):
git-svn: Don't call git-repack anymore
Let "git svn" run "git gc --auto" occasionally
Linus Torvalds (3):
Make on-disk index representation separate from in-core one
Make run_diff_index() use unpack_trees(), not read_tree()
Create pathname-based hash-table lookup into index
Martin Koegler (2):
git-fsck: report missing author/commit line in a commit as an error
parse_object_buffer: don't ignore errors from the object specific parsing
functions
Michael Witten (3):
git-send-email: ssh/login style password requests
git-send-email: SIG{TERM,INT} handlers
git-send-email: Better handling of EOF
Mike Hommey (1):
Work around curl-gnutls not liking to be reinitialized
Pierre Habouzit (2):
git-describe: Add a --match option to limit considered tags.
git-name-rev: add a --(no-)undefined option.
Rafael Garcia-Suarez (1):
Make git-remote.perl "use strict" compliant
Robin Rosenberg (1):
Improve bash prompt to detect various states like an unfinished merge
Simon Hausmann (2):
git-p4: Fix submit user-interface.
git-p4: Ensure the working directory and the index are clean before
"git-p4 rebase"
Tim Stoakes (1):
Add `git svn blame' command
Toby Allsopp (1):
git-p4: Fix indentation from tab to spaces
Tommy Thorn (1):
git-p4: Fix an obvious typo
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-02-12 7:25 ` What's in git.git Junio C Hamano
@ 2008-02-17 3:56 ` Junio C Hamano
2008-02-17 13:39 ` Jakub Narebski
2008-02-21 4:16 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-02-17 3:56 UTC (permalink / raw)
To: git
I'll hopefully soon apply the RPM spec patch from Kristian
Høgsberg to 'maint' and cut 1.5.4.2. It will have bunch of
config parser related fixes among others.
On the 'master' front, a handful topics have graduated:
- Brian Downing's compat/qsort;
- Crhstian Couder's browser wrapper;
- Paolo Bonzini's prepare-commit-msg hook;
- Steffen Prohaska's safe-crlf;
- "foo/" in .gitignore matches directory "foo".
Also, updated versions of gitk and git-gui are included.
Have fun.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Christian Couder (8):
config: add test cases for empty value and no value config variables.
diff.c: replace a 'strdup' with 'xstrdup'.
diff.c: remove useless check for value != NULL
config: add 'git_config_string' to refactor string config variables.
Add "const" qualifier to "char *pager_program".
Add "const" qualifier to "char *editor_program".
Add "const" qualifier to "char *excludes_file".
diff.c: add "const" qualifier to "char *cmd" member of "struct
ll_diff_driver"
Daniel Barkalow (1):
Validate nicknames of remote branches to prohibit confusing ones
Gerrit Pape (1):
cvsimport: have default merge regex also match beginning of commit
message
Jay Soffian (1):
mailinfo: feed only one line to handle_filter() for QP input
Jeff King (2):
status: suggest "git rm --cached" to unstage for initial commit
commit: discard index after setting up partial commit
Johannes Schindelin (1):
bisect: use verbatim commit subject in the bisect log
Johannes Sixt (1):
upload-pack: Initialize the exec-path.
Junio C Hamano (6):
Revert "pack-objects: only throw away data during memory pressure"
Protect get_author_ident_from_commit() from filenames in work tree
diff.c: fixup garding of config parser from value=NULL
diff: Fix miscounting of --check output
filter-branch: handle filenames that need quoting
Documentation/git-reset:
Miklos Vajna (1):
git clone -s documentation: force a new paragraph for the NOTE
Pieter de Bie (2):
Documentation/git-reset: don't mention --mixed for selected-paths reset
Documentation/git-reset: Add an example of resetting selected paths
Sergei Organov (1):
git-cvsimport.txt: fix '-M' description.
Shawn O. Pearce (1):
fast-import: check return value from unpack_entry()
Stelian Pop (1):
hg-to-git: fix parent analysis
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Brian Downing (1):
compat: Add simplified merge sort implementation from glibc
Christian Couder (7):
help: make 'git-help--browse' usable outside 'git-help'.
help--browse: add '--config' option to check a config option for a
browser.
Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
instaweb: use 'git-web--browse' to launch browser.
Documentation: instaweb: add 'git-web--browse' information.
web--browse: Add a few quotes in 'init_browser_path'.
Documentation: add 'git-web--browse.txt' and simplify other docs.
Christian Stimming (2):
git-gui: (i18n) Fix a bunch of still untranslated strings.
git-gui: Update German translation.
Dmitry Potapov (1):
git-web--browse: do not start the browser with nohup
Gerrit Pape (1):
gitk: properly deal with tag names containing / (slash)
Jay Soffian (3):
git-gui: support Git Gui.app under OS X 10.5
git-help--browse: improve browser support under OS X
git-web--browse: fix misplaced quote in init_browser_path()
Jeff King (2):
allow suppressing of global and system config
fix config reading in tests
Johan Herland (2):
Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
$GIT_DIR
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
Johannes Schindelin (1):
Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
Johannes Sixt (1):
gitk: Heed the lines of context in merge commits
Junio C Hamano (7):
Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject
header
Documentation/SubmittingPatches: discuss first then submit
Documentation/SubmittingPatches: What's Acked-by and Tested-by?
gitignore(5): Allow "foo/" in ignore list to match directory "foo"
gitignore: lazily find dtype
.mailmap: adjust to a recent patch application glitch.
Documentation/SubmittingPatches - a suggested patch flow
Linus Torvalds (1):
gitk: learn --show-all output
Michele Ballabio (1):
gitk: Fix "Key bindings" message
Paolo Bonzini (4):
git-commit: support variable number of hook arguments
git-commit: set GIT_EDITOR=: if editor will not be launched
git-commit: Refactor creation of log message.
git-commit: add a prepare-commit-msg hook
Shawn O. Pearce (7):
git-gui: Automatically spell check commit messages as the user types
git-gui: Paper bag fix bad string length call in spellchecker
git-gui: Correct size of dictionary name widget in options dialog
Include annotated tags in fast-import crash reports
Include the fast-import marks table in crash reports
Finish current packfile during fast-import crash handler
Update fast-import documentation to discuss crash reports
Steffen Prohaska (2):
safecrlf: Add mechanism to warn about irreversible crlf conversions
gitk: Add checkbutton to ignore space changes
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-17 3:56 ` What's in git.git (stable) Junio C Hamano
@ 2008-02-17 13:39 ` Jakub Narebski
2008-02-17 20:45 ` Junio C Hamano
2008-02-21 4:16 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2008-02-17 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> On the 'master' front, a handful topics have graduated:
>
> - Brian Downing's compat/qsort;
> - Crhstian Couder's browser wrapper;
> - Paolo Bonzini's prepare-commit-msg hook;
> - Steffen Prohaska's safe-crlf;
> - "foo/" in .gitignore matches directory "foo".
Nice.
> Daniel Barkalow (1):
> Validate nicknames of remote branches to prohibit confusing ones
Good one.
> Jeff King (2):
> status: suggest "git rm --cached" to unstage for initial commit
Corner case, but good one.
> commit: discard index after setting up partial commit
IIRC there was also request for proper solution; this was more a hack.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-17 13:39 ` Jakub Narebski
@ 2008-02-17 20:45 ` Junio C Hamano
2008-02-17 20:51 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-17 20:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
>> commit: discard index after setting up partial commit
>
> IIRC there was also request for proper solution; this was more a hack.
It is not a hack at all.
The more fundamental improvement was along the lines of what I
suggested soon after Kristian's initial round was posted, but
what the current code does is not wrong nor hack. It is about a
partial commit after all and is not performance critical either.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-17 20:45 ` Junio C Hamano
@ 2008-02-17 20:51 ` Johannes Schindelin
2008-02-18 1:31 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-17 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
Hi,
On Sun, 17 Feb 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> >> commit: discard index after setting up partial commit
> >
> > IIRC there was also request for proper solution; this was more a hack.
>
> It is not a hack at all.
>
> The more fundamental improvement was along the lines of what I suggested
> soon after Kristian's initial round was posted, but what the current
> code does is not wrong nor hack. It is about a partial commit after all
> and is not performance critical either.
You mean: at this point, it is not necessary to be careful about the
index, as the index that will be reloaded will already have the most
recent timestamps, right?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-17 20:51 ` Johannes Schindelin
@ 2008-02-18 1:31 ` Junio C Hamano
2008-02-18 1:34 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-18 1:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 17 Feb 2008, Junio C Hamano wrote:
>
>> The more fundamental improvement was along the lines of what I suggested
>> soon after Kristian's initial round was posted, but what the current
>> code does is not wrong nor hack. It is about a partial commit after all
>> and is not performance critical either.
>
> You mean: at this point, it is not necessary to be careful about the
> index, as the index that will be reloaded will already have the most
> recent timestamps, right?
I do not understand the question, but if you are referring to my
"not performance critical", I meant: "A partial commit is
never performance critical".
A partial commit is by its nature "oops, I earlier told you to
git add this and git add that but I did not mean that, eh, I do
mean it but not for this commit yet, sorry, I want to commit
changes to these paths first please and then I'll deal with the
earlier added paths in later commit perhaps.", i.e. very
interactive. Its performance requirement is unlike an automated
script slurping hundreds of changes per minute applying exactly
the change it wants in each commit to the index and making
commits in rapid succession.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-18 1:31 ` Junio C Hamano
@ 2008-02-18 1:34 ` Johannes Schindelin
2008-02-18 1:43 ` Jeff King
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-18 1:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
Hi,
On Sun, 17 Feb 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 17 Feb 2008, Junio C Hamano wrote:
> >
> >> The more fundamental improvement was along the lines of what I suggested
> >> soon after Kristian's initial round was posted, but what the current
> >> code does is not wrong nor hack. It is about a partial commit after all
> >> and is not performance critical either.
> >
> > You mean: at this point, it is not necessary to be careful about the
> > index, as the index that will be reloaded will already have the most
> > recent timestamps, right?
>
> I do not understand the question, but if you are referring to my "not
> performance critical", I meant: "A partial commit is never performance
> critical".
>
> A partial commit is by its nature "oops, I earlier told you to git add
> this and git add that but I did not mean that, eh, I do mean it but not
> for this commit yet, sorry, I want to commit changes to these paths
> first please and then I'll deal with the earlier added paths in later
> commit perhaps.", i.e. very interactive. Its performance requirement is
> unlike an automated script slurping hundreds of changes per minute
> applying exactly the change it wants in each commit to the index and
> making commits in rapid succession.
Well, my workflow has lots of these moments. I do not even feel "oops"
about it. More like "by the way, this needs committing _now_".
So I guess I'll be the guinea pig for this patch, and if it is too
painful, I'll just go and fix it.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-18 1:34 ` Johannes Schindelin
@ 2008-02-18 1:43 ` Jeff King
2008-02-18 2:05 ` Johannes Schindelin
2008-02-18 3:12 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Jeff King @ 2008-02-18 1:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jakub Narebski, git
On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:
> Well, my workflow has lots of these moments. I do not even feel "oops"
> about it. More like "by the way, this needs committing _now_".
>
> So I guess I'll be the guinea pig for this patch, and if it is too
> painful, I'll just go and fix it.
Just to be clear, this patch discards the cache after preparing the
partial index but before doing the status. This is in contrast to the
current 'master' and v1.5.4, which discard the cache _three_ times
during the status process.
So no, the performance will probably not be a big deal. It is better
than it has been in any released version of git.
-Peff
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-18 1:43 ` Jeff King
@ 2008-02-18 2:05 ` Johannes Schindelin
2008-02-18 3:12 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2008-02-18 2:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jakub Narebski, git
Hi,
On Sun, 17 Feb 2008, Jeff King wrote:
> On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:
>
> > Well, my workflow has lots of these moments. I do not even feel "oops"
> > about it. More like "by the way, this needs committing _now_".
> >
> > So I guess I'll be the guinea pig for this patch, and if it is too
> > painful, I'll just go and fix it.
>
> Just to be clear, this patch discards the cache after preparing the
> partial index but before doing the status. This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.
... but then goes through big pains to reconstruct an index that needs as
little updating as possible.
> So no, the performance will probably not be a big deal. It is better
> than it has been in any released version of git.
I'll see, and report back.
IOW I think that your patch is necessary. There might be some followup
work to do for me, but at the moment, your patch fixes an existing bug.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-18 1:43 ` Jeff King
2008-02-18 2:05 ` Johannes Schindelin
@ 2008-02-18 3:12 ` Junio C Hamano
2008-02-18 11:15 ` Jeff King
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-18 3:12 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Jakub Narebski, git
Jeff King <peff@peff.net> writes:
> .... This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.
The current 'master' meaning before 959ba67 (commit: discard
index after setting up partial commit), right?
I've been hoping that when this turns out to be Ok it would be
worth cherry-picking to 'maint' before 1.5.4.3.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-02-18 3:12 ` Junio C Hamano
@ 2008-02-18 11:15 ` Jeff King
0 siblings, 0 replies; 601+ messages in thread
From: Jeff King @ 2008-02-18 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jakub Narebski, git
On Sun, Feb 17, 2008 at 07:12:53PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > .... This is in contrast to the
> > current 'master' and v1.5.4, which discard the cache _three_ times
> > during the status process.
>
> The current 'master' meaning before 959ba67 (commit: discard
> index after setting up partial commit), right?
Heh. Yes. The current 'master' meaning 'the current master when I wrote
that patch.' :)
-Peff
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-02-17 3:56 ` What's in git.git (stable) Junio C Hamano
2008-02-17 13:39 ` Jakub Narebski
@ 2008-02-21 4:16 ` Junio C Hamano
2008-02-25 8:42 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-21 4:16 UTC (permalink / raw)
To: git
With a handful of fixes and RPM specfile updates, we would
probably want to do 1.5.4.3 in a week or so from 'maint'.
A handful of new topics are now on 'master', and the ones still
on 'next' are maturing with necessary fixes. I think we have
enough material for 1.5.5 when they graduate, and I am hoping to
do an rc1 sometime early to mid next month. We'll see.
* The 'maint' branch has these fixes since the last announcement.
Gerrit Pape (1):
git-clone.sh: properly configure remote even if remote's head is dangling
Jay Soffian (1):
send-email: squelch warning due to comparing undefined $_ to ""
Jeff King (3):
push: indicate partialness of error message
Documentation/push: clarify matching refspec behavior
push: document the status output
Junio C Hamano (1):
GIT 1.5.4.2
Kristian Høgsberg (1):
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
Miklos Vajna (1):
Documentation/git-stash: document options for git stash list
Pekka Kaitaniemi (1):
Clarified the meaning of git-add -u in the documentation
* The 'master' branch has these since the last announcement
in addition to the above.
Brandon Casey (1):
Add compat/fopen.c which returns NULL on attempt to open directory
Bruno Ribas (1):
gitweb: Use the config file to set repository owner's name.
Christian Couder (1):
help.c: use 'git_config_string' to get 'help_default_format'.
Daniel Barkalow (1):
API documentation for remote.h
David Kågedal (1):
git.el: Set process-environment instead of invoking env
Jakub Narebski (3):
gitweb: Fix displaying unchopped argument in chop_and_escape_str
gitweb: Add new option -nohtml to quot_xxx subroutines
gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form
Jay Soffian (1):
Correct git-pull documentation
Jeff King (2):
hard-code the empty tree object
add--interactive: handle initial commit better
Johannes Schindelin (5):
http-push: avoid invalid memory accesses
http-push: do not get confused by submodules
http-push: avoid a needless goto
bisect view: check for MinGW32 and MacOSX in addition to X11
cvsexportcommit: be graceful when "cvs status" reorders the arguments
Johannes Sixt (1):
Technical documentation of the run-command API.
Junio C Hamano (5):
setup: sanitize absolute and funny paths in get_pathspec()
git-add: adjust to the get_pathspec() changes.
builtin-mv: minimum fix to avoid losing files
Sync with 1.5.4.2 and start 1.5.5 Release Notes
sending errors to stdout under $PAGER
Lars Hjemli (1):
Simplify setup of $GIT_DIR in git-sh-setup.sh
Linus Torvalds (1):
Add "--show-all" revision walker flag for debugging
Marco Costalba (1):
Avoid a useless prefix lookup in strbuf_expand()
Martin Koegler (15):
deref_tag: handle return value NULL
deref_tag: handle tag->tagged = NULL
check return code of prepare_revision_walk
read_object_with_reference: don't read beyond the buffer
get_sha1_oneline: check return value of parse_object
mark_blob/tree_uninteresting: check for NULL
reachable.c::add_one_tree: handle NULL from lookup_tree
list-objects.c::process_tree/blob: check for NULL
check results of parse_commit in merge_bases
process_tag: handle tag->tagged == NULL
reachable.c::process_tree/blob: check for NULL
revision.c: handle tag->tagged == NULL
parse_commit: don't fail, if object is NULL
check return value from parse_commit() in various functions
peel_onion: handle NULL
Matthias Kestenholz (1):
Add color.ui variable which globally enables colorization if set
Robin Rosenberg (1):
Make blame accept absolute paths
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-02-21 4:16 ` Junio C Hamano
@ 2008-02-25 8:42 ` Junio C Hamano
2008-02-28 0:43 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-25 8:42 UTC (permalink / raw)
To: git
By the end of this week, we will hopefully pretty much know what
will be (and what won't be) in 1.5.5. Tonight's 'master'
contains Linus's "diff --dirstat" and my "apply ---whitespace"
enhancements, among other things. The next 'master' update is
expected to be fairly big (see "What's cooking").
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.4.3
Shawn O. Pearce (3):
Ensure 'make dist' compiles git-archive.exe on Cygwin
Protect peel_ref fallback case from NULL parse_object result
Correct fast-export file mode strings to match fast-import standard
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Gerrit Pape (2):
git-merge-index documentation: clarify synopsis
builtin-tag.c: remove cruft
Jakub Narebski (1):
gitweb: Fix bugs in git_search_grep_body: it's length(), not len()
Jay Soffian (2):
send-email: fix In-Reply-To regression
pull: pass --strategy along to to rebase
Jeff King (5):
git_config_*: don't assume we are parsing a config file
t3404: use configured shell instead of /bin/sh
diff: fix java funcname pattern for solaris
t9001: enhance fake sendmail test harness
send-email: test compose functionality
Johannes Sixt (1):
prefix_path: use is_absolute_path() instead of *orig == '/'
Junio C Hamano (18):
builtin-apply.c: refactor small part that matches context
builtin-apply.c: restructure "offset" matching
builtin-apply.c: push match-beginning/end logic down
builtin-apply.c: make it more line oriented
builtin-apply.c: optimize match_beginning/end processing a bit.
builtin-apply.c: mark common context lines in lineinfo structure.
builtin-apply.c: clean-up apply_one_fragment()
builtin-apply.c: simplify calling site to apply_line()
builtin-apply.c: do not feed copy_wsfix() leading '+'
builtin-apply.c: move copy_wsfix() function a bit higher.
builtin-apply.c: pass ws_rule down to match_fragment()
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous
run
core.whitespace: cr-at-eol
apply: do not barf on patch with too large an offset
git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
gitweb: Better chopping in commit search results
ws_fix_copy(): move the whitespace fixing function to ws.c
diff --dirstat: saner handling of binary and unmerged files
Linus Torvalds (5):
Add "--dirstat" for some directory statistics
Fix name re-hashing semantics
Name hash fixups: export (and rename) remove_hash_entry
Use helper function for copying index entry information
Be more verbose when checkout takes a long time
Michele Ballabio (1):
builtin-for-each-ref.c: fix typo in error message
Miklos Vajna (1):
git-clean: handle errors if removing files fails
Santi Béjar (1):
git-bundle.txt: Add different strategies to create the bundle
Shawn O. Pearce (1):
Teach git-grep --name-only as synonym for -l
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-02-25 8:42 ` Junio C Hamano
@ 2008-02-28 0:43 ` Junio C Hamano
2008-03-03 2:06 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-02-28 0:43 UTC (permalink / raw)
To: git
For the next maintenance release v1.5.4.4, I made a few
cherry-picks from 'master' and also a merge down of a topic
branch that has been cooking there, to 'maint'.
On the 'master' front, many topics have been merged. With a few
more topics that are still in 'next', we are pretty much done
feature-wise for the next feature release v1.5.5.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Brandon Casey (1):
builtin-reflog.c: don't install new reflog on write failure
Bryan Donlan (1):
Documentation/git-am.txt: Pass -r in the example invocation of rm -f
.dotest
Caio Marcelo de Oliveira Filho (1):
filter-branch documentation: non-zero exit status in command abort the
filter
Carl Worth (1):
Eliminate confusing "won't bisect on seeked tree" failure
Daniel Barkalow (2):
Use a single implementation and API for copy_file()
Don't use GIT_CONFIG in t5505-remote
Jay Soffian (2):
rev-parse: fix potential bus error with --parseopt option spec handling
send-email: fix In-Reply-To regression
Johan Herland (2):
Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
$GIT_DIR
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
Johannes Schindelin (3):
http-push: avoid invalid memory accesses
http-push: do not get confused by submodules
http-push: avoid a needless goto
Jonathan del Strother (1):
Prompt to continue when editing during rebase --interactive
Miklos Vajna (2):
Documentation/git-filter-branch: add a new msg-filter example
Documentation/git svn log: add a note about timezones.
Steven Drake (1):
timezone_names[]: fixed the tz offset for New Zealand.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alexandre Julliard (1):
git.el: Do not display empty directories.
Andreas Ericsson (1):
pack-objects: Add runtime detection of online CPU's
Brandon Casey (2):
builtin-reflog.c: don't install new reflog on write failure
pack-objects: Print a message describing the number of threads for packing
Carl Worth (1):
Eliminate confusing "won't bisect on seeked tree" failure
Daniel Barkalow (26):
Allow callers of unpack_trees() to handle failure
Add flag to make unpack_trees() not print errors.
Send unpack-trees debugging output to stderr
Discard "deleted" cache entries after using them to update the working tree
Add "skip_unmerged" option to unpack_trees.
Build-in merge-recursive
Move create_branch into a library file
Use diff -u instead of diff in t7201
Library function to check for unmerged index entries
Move code to clean up after a branch change to branch.c
Build in checkout
Clean up reporting differences on branch switch
Add more tests for format-patch
Improve message-id generation flow control for format-patch
Export some email and pretty-printing functions
Use ALLOC_GROW in remote.{c,h}
Add a --cover-letter option to format-patch
Add tests for extra headers in format-patch
Fix format.headers not ending with a newline
Combine To: and Cc: headers
Support a --cc=<email> option in format-patch
Resolve value supplied for no-colon push refspecs
builtin-checkout.c: Remove unused prefix arguments in switch_branches path
Add support for url aliases in config files
Add API access to shortlog
Improve collection of information for format-patch --cover-letter
Gerrit Pape (1):
hash-object: cleanup handling of command line options
Jakub Narebski (2):
gitweb: Better cutting matched string and its context
Add '--fixed-strings' option to "git log --grep" and friends
Jay Soffian (3):
builtin-checkout.c: fix possible usage segfault
branch: optionally setup branch.*.merge from upstream local branches
doc: documentation update for the branch track changes
Jeff King (3):
help: use parseopt
make alias lookup a public, procedural function
help: respect aliases
Jim Meyering (1):
Avoid unnecessary "if-before-free" tests.
Johannes Schindelin (2):
xdl_merge(): make XDL_MERGE_ZEALOUS output simpler
xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM
Johannes Sixt (2):
start_command(), .in/.out/.err = -1: Callers must close the file descriptor
start_command(), if .in/.out > 0, closes file descriptors, not the callers
Junio C Hamano (12):
diff --relative: output paths as relative to the current subdirectory
diff --relative: help working in a bare repository
checkout: notice when the switched branch is behind or forked
checkout: tone down the "forked status" diagnostic messages
checkout: work from a subdirectory
checkout: updates to tracking report
Add merge-subtree back
checkout: show progress when checkout takes long time while switching
branches
checkout: error out when index is unmerged even with -m
url rewriting: take longest and first match
git-apply --whitespace=fix: fix off by one thinko
Revert "pack-objects: Print a message describing the number of threads
for packing"
Sebastian Noack (1):
git-svn: Don't prompt for client cert password everytime.
Shawn O. Pearce (5):
Optimize peel_ref for the current ref of a for_each_ref callback
Teach git-describe to use peeled ref information when scanning tags
Avoid accessing non-tag refs in git-describe unless --all is requested
Teach git-describe --exact-match to avoid expensive tag searches
Use git-describe --exact-match in bash prompt on detached HEAD
Simon Hausmann (4):
git-p4: Remove --log-substitutions feature.
git-p4: Clean up git-p4 submit's log message handling.
git-p4: Removed git-p4 submit --direct.
git-p4: git-p4 submit cleanups.
Steffen Prohaska (2):
t4014: Replace sed's non-standard 'Q' by standard 'q'
Add tests for filesystem challenges (case and unicode normalization)
Tommy Thorn (1):
git-p4: support exclude paths
Tor Arvid Lund (1):
git-p4: Support usage of perforce client spec
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-02-28 0:43 ` Junio C Hamano
@ 2008-03-03 2:06 ` Junio C Hamano
2008-03-06 6:02 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-03 2:06 UTC (permalink / raw)
To: git
The 'master' has, aside from trivial fixes and enhancements, the following
topics that have been cooking:
* "verify-pack" improvements;
* "describe" that warns about a tag whose name and path contradict;
* "describe --long" to show an tagged commit as $tag-0-$sha1;
* "cvsimport -M" can be given more than once;
* "gitweb" grep-search improvements;
A handful of the topics are meant also for 'maint'; after seeing no
complaints for a while they will be merged to 'maint' as part of the next
maintenance release v1.5.4.4.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Daniel Barkalow (1):
Correct name of diff_flush() in API documentation
Gerrit Pape (1):
templates/Makefile: don't depend on local umask setting
Junio C Hamano (1):
Start preparing for 1.5.4.4
Mike Ralphson (1):
Documentation cherry-pick: Fix cut-and-paste error
Rémi Vanicat (1):
git.el: find the git-status buffer whatever its name is
Shawn O. Pearce (1):
git-gui: Paper bag fix info dialog when no files are staged at commit
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix builtin checkout crashing when given an invalid path
Christian Stimming (2):
git-gui: (i18n) Add newly added translation strings to template.
git-gui: Update German translation.
Clemens Buchacher (2):
http-push: push <remote> :<branch> deletes remote branch
http-push: add regression tests
Daniel Barkalow (3):
Always use the current connection's remote ref list in git protocol
Use diff_tree() directly in making cover letter
Write index file on any checkout of files
Denis Cheng (1):
cleanup: remove unused git_checkout_config
Frank Lichtenheld (1):
gc: Add --quiet option
Jakub Narebski (4):
gitweb: Change parse_commits signature to allow for multiple options
gitweb: Simplify fixed string search
Documentation: Remove --{min,max}-age option from git-log(1)
gitweb: Mark first match when searching commit messages
Jean-Luc Herren (1):
fast-import: exit with proper message if not a git dir
Jeff King (3):
use build-time SHELL_PATH in test scripts
rename: warn user when we have turned off rename detection
allow git-am to run in a subdirectory
Johannes Schindelin (4):
completion: support format-patch's --cover-letter option
Fix make_absolute_path() for parameters without a slash
format-patch: use the diff options for the cover letter, too
format-patch: wrap cover-letter's shortlog sensibly
Johannes Sixt (2):
daemon: send more error messages to the syslog
daemon: ensure that base-path is an existing directory
Junio C Hamano (11):
git-remote: do not complain on multiple URLs for a remote
Fix "git log --merge --left-right"
format-patch: remove a leftover debugging message
tests: introduce test_must_fail
Update draft release notes for 1.5.5
t6024: move "git reset" to prepare for a test inside the test itself
CodingGuidelines: spell out how we use grep in our scripts
find_unique_abbrev(): redefine semantics
Clean up find_unique_abbrev() callers
diff-lib.c: constness strengthening
diff: make sure work tree side is shown as 0{40} when different
Martin Koegler (10):
add generic, type aware object chain walker
builtin-fsck: move away from object-refs to fsck_walk
Remove unused object-ref code
builtin-fsck: reports missing parent commits
builtin-fsck: move common object checking code to fsck.c
add common fsck error printing function
unpack-object: cache for non written objects
unpack-objects: prevent writing of inconsistent objects
index-pack: introduce checking mode
receive-pack: use strict mode for unpacking objects
Michele Ballabio (1):
git-gui: fix typo in lib/spellcheck.tcl
Mike Hommey (4):
Set proxy override with http_init()
Add test for git rebase --abort
Documentation/git-rebase.txt: Add --strategy to synopsys
git rebase --abort: always restore the right commit
Miklos Vajna (1):
Improve t6029 to check the real "subtree" case
Nicolas Pitre (4):
factorize revindex code out of builtin-pack-objects.c
make verify_one_pack() a bit less wrong wrt packed_git structure
fix unimplemented packed_object_info_detail() features
add storage size output to 'git verify-pack -v'
Petr Baudis (1):
gitweb: Clearly distinguish regexp / exact match searches
Philippe Bruhat (BooK (3):
cvsimport: have default merge regex allow for dashes in the branch name
cvsimport: allow for multiple -M options
cvsimport: document that -M can be used multiple times
Ralf Wildenhues (1):
Fix doc typos.
Santi Béjar (2):
git-describe: --long shows the object name even for a tagged commit
clone: support cloning full bundles
Sebastian Noack (1):
git-svn: Don't prompt for client cert password everytime.
Shawn O. Pearce (7):
git-gui: Ensure all spellchecker 'class' variables are initialized
git-gui: Remove explicit references to 'aspell' in message strings
git-gui: Only bind the spellcheck popup suggestion hook once
git-gui: Catch and display aspell startup failures to the user
git-gui: Gracefully display non-aspell version errors to users
git-gui: Shorten Aspell version strings to just Aspell version number
Teach git-describe to verify annotated tag names before output
Uwe Kleine-König (1):
rev-list: add --branches, --tags and --remotes
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-03 2:06 ` Junio C Hamano
@ 2008-03-06 6:02 ` Junio C Hamano
2008-03-08 10:08 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-06 6:02 UTC (permalink / raw)
To: git
I should probably do a 1.5.4.4 shortly from 'maint' to flush accumulated
fixes. There is nothing major, but send-email regression fix deserves to
be delibered sooner to the end users.
On the 'master', we briefly had a faulty receive-pack to cause a small
pushes to fail, but that glitch has been reverted. Also fixed was a
git-describe not quite working when your tags are packed (e.g. after
git-gc).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (1):
receive-pack: Initialize PATH to include exec-dir.
Gerrit Pape (1):
git-merge.sh: better handling of combined --squash,--no-ff,--no-commit
options
Jeff King (1):
revert: actually check for a dirty index
Junio C Hamano (2):
tests: introduce test_must_fail
Update draft release notes for 1.5.4.4
Matthieu Moy (1):
Fix incorrect wording in git-merge.txt.
Mike Hommey (1):
Fix random crashes in http_cleanup()
Ping Yin (1):
git-submodule: Fix typo 'url' which should be '$url'
Shawn O. Pearce (1):
Fix 'git remote show' regression on empty repository in 1.5.4
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix test for cleanup failure in t7300 on Windows
Junio C Hamano (8):
Update draft release notes for 1.5.5
git-describe: use tags found in packed-refs correctly
describe: fix --long output
describe: re-fix display_name()
t6120 (describe): check --long properly
Revert "receive-pack: use strict mode for unpacking objects"
Revert "unpack-objects: prevent writing of inconsistent objects"
fsck.c: fix bogus "empty tree" check
Martin Koegler (1):
fetch-pack: check parse_commit/object results
Mike Hommey (1):
t3407-rebase-abort.sh: Enhance existing tests, and add test for rebase
--merge
SZEDER Gábor (2):
bash: add git-branch options
bash: git-branch -d and -m lists only local branches
Shawn O. Pearce (3):
Don't allow git-describe failures to go unnoticed in t6120
Test for packed tags in git-describe output
Add git-describe test for "verify annotated tag names on output"
Simon Hausmann (1):
git-p4: Fix import of changesets with file deletions
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-06 6:02 ` Junio C Hamano
@ 2008-03-08 10:08 ` Junio C Hamano
2008-03-09 10:46 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-08 10:08 UTC (permalink / raw)
To: git
There are about half a dozen topics that need to be merged to 'maint'
before 1.5.4.4 can happen, which hopefully will be mid next week. They
are already in 'master' and we haven't heard about breakages with them.
It would be really nice to also have msgfmt issue on OSX resolved (e.g.
http://article.gmane.org/gmane.comp.version-control.git/76355) before
that.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (1):
test-lib: fix TERM to dumb for test repeatability
Pierre Habouzit (1):
unquote_c_style: fix off-by-one.
Shawn O. Pearce (1):
git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails
Uwe Kleine-König (1):
config.txt: refer to --upload-pack and --receive-pack instead of --exec
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Do not use GUID on dir in git init --shared=all on FreeBSD
Brandon Casey (10):
builtin-reflog.c: fix typo that accesses an unset variable
reflog-delete: parse standard reflog options
git-reflog: add option --rewrite to update reflog entries while expiring
refs.c: make close_ref() and commit_ref() non-static
git-reflog: add option --updateref to write the last reflog sha1 into the
ref
git-stash: add new 'drop' subcommand
git-stash: add new 'pop' subcommand
t3903-stash.sh: Add missing '&&' to body of testcase
git-reflog.txt: Document new commands --updateref and --rewrite
t3903-stash.sh: Add tests for new stash commands drop and pop
Charles Bailey (4):
Tidy up git mergetool's backup file behaviour
Changed an internal variable of mergetool to support custom commands
Teach git mergetool to use custom commands defined at config time
Add a very basic test script for git mergetool
Christian Couder (1):
run-command: Redirect stderr to a pipe before redirecting stdout to
stderr
Denis Cheng (3):
whatchanged documentation: share description of --pretty with others
specify explicit "--pretty=medium" with `git log/show/whatchanged`
log/show/whatchanged: introduce format.pretty configuration
Johannes Schindelin (1):
Teach "git reflog" a subcommand to delete single entries
Junio C Hamano (1):
send-email: --no-signed-off-cc should suppress 'sob' cc
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-08 10:08 ` Junio C Hamano
@ 2008-03-09 10:46 ` Junio C Hamano
2008-03-14 9:11 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-09 10:46 UTC (permalink / raw)
To: git
Maintenance release 1.5.4.4 is out with accumulated fixes.
Except for a few remaining topics ("remote rewritten in C", and "saner
unpack_trees"), 'master' is almost feature complete for 1.5.5 and we will
hopefully soon enter -rc freeze.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Adeodato Simó (1):
Really make the LF after reset in fast-import optional
Johannes Schindelin (1):
cvsexportcommit: be graceful when "cvs status" reorders the arguments
Johannes Sixt (2):
daemon: send more error messages to the syslog
daemon: ensure that base-path is an existing directory
John Goerzen (1):
Fix dcommit, rebase when rewriteRoot is in use
Junio C Hamano (2):
Fix "git log --merge --left-right"
GIT 1.5.4.4
Mike Hommey (1):
Set proxy override with http_init()
Santi Béjar (1):
ident.c: reword error message when the user name cannot be determined
Sebastian Noack (1):
git-svn: Don't prompt for client cert password everytime.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Whitcroft (1):
shortlog: take the first populated line of the description
Carlos Rica (1):
Make builtin-reset.c use parse_options.
Charles Bailey (2):
git-mergetool documentaiton: show toolnames in typewriter font
merge-tool documentation: describe custom command usage
Dmitry Potapov (2):
Make private quote_path() in wt-status.c available as
quote_path_relative()
git-clean: correct printing relative path
Jakub Narebski (1):
gitweb: Fix and simplify pickaxe search
Jeff King (1):
Add a test for read-tree -u --reset with a D/F conflict
Junio C Hamano (10):
describe --always: fall back to showing an abbreviated object name
am: read from the right mailbox when started from a subdirectory
am: remove support for -d .dotest
am: --rebasing
get_pathspec(): die when an out-of-tree path is given
Revert part of 744dacd (builtin-mv: minimum fix to avoid losing files)
Revert part of 1abf095 (git-add: adjust to the get_pathspec() changes)
Revert part of d089eba (setup: sanitize absolute and funny paths in
get_pathspec())
git-clean: add tests for relative path
filter-branch: handle "disappearing tree" case correctly in subdir filter
Mark Levedahl (1):
git-submodule - Allow adding a submodule in-place
Michal Rokos (1):
Add compat/snprintf.c for systems that return bogus
Pierre Habouzit (2):
parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --parseopt
parse-options: new option type to treat an option-like parameter as an
argument.
Shawn O. Pearce (11):
Remove unused variable in builtin-fetch find_non_local_tags
Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
Ensure tail pointer gets setup correctly when we fetch HEAD only
Allow builtin-fetch's find_non_local_tags to append onto a list
Free the path_lists used to find non-local tags in git-fetch
Teach upload-pack to log the received need lines to an fd
Make git-fetch follow tags we already have objects for sooner
Teach git-fetch to grab a tag at the same time as a commit
git-pack-objects: Automatically pack annotated tags if object was packed
Teach fetch-pack/upload-pack about --include-tag
Teach git-fetch to exploit server side automatic tag following
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-09 10:46 ` Junio C Hamano
@ 2008-03-14 9:11 ` Junio C Hamano
2008-03-23 10:08 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-14 9:11 UTC (permalink / raw)
To: git
We still have remaining fixes and a handful backports (cherry-picks) from
'master' to 'maint', and we would probably need v1.5.4.5 shortly.
On the 'master' front, we have git-gui updates, more bash completion, and
a few recent graduates (rewrite of unpack_trees(), reimplementation of
git-remote).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Andy Whitcroft (1):
shortlog: take the first populated line of the description
Clemens Buchacher (1):
merge-recursive: handle file mode changes
Jakub Narebski (1):
gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form
Jeff King (1):
t0021: tr portability fix for Solaris
Johannes Schindelin (3):
launch_editor(): allow spaces in the filename
git fetch: Take '-n' to mean '--no-tags'
merge-file: handle empty files gracefully
Junio C Hamano (3):
filter-branch: handle "disappearing tree" case correctly in subdir filter
git-pull documentation: warn about the option order
quiltimport: fix misquoting of parsed -p<num> parameter
Marc-Andre Lureau (2):
git-svn: fix find-rev error message when missing arg
git-cvsimport: fix merging with remote parent branch
Mike Hommey (1):
git rebase --abort: always restore the right commit
Pierre Habouzit (1):
git-quiltimport: better parser to grok "enhanced" series files.
Vineet Kumar (1):
Minor wording changes in the keyboard descriptions in git-add
--interactive.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Piątyszek (1):
git-gui: Add option for changing the width of the commit message text box
Christian Couder (2):
web--browse: use custom commands defined at config time
Documention: web--browse: add info about "browser.<tool>.cmd" config var
Johannes Schindelin (9):
path-list: add functions to work with unsorted lists
parseopt: add flag to stop on first non option
Test "git remote show" and "git remote prune"
Make git-remote a builtin
builtin-remote: prune remotes correctly that were added with --mirror
remote show: Clean up connection correctly if object fetch wasn't done
remote: fix "update [group...]"
builtin remote rm: remove symbolic refs, too
gc: call "prune --expire 2.weeks.ago" by default
Junio C Hamano (6):
merge-recursive: split low-level merge functions out.
expose a helper function peel_to_type().
traverse_trees_recursive(): propagate merge errors up
git-gui: Simplify MSGFMT setting in Makefile
Documentation/config: typofix
read-tree() and unpack_trees(): use consistent limit
Kevin Ballard (1):
bash: Properly quote the GIT_DIR at all times to fix subdirectory paths
with spaces
Linus Torvalds (11):
Add 'df_name_compare()' helper function
Make 'traverse_tree()' use linked structure rather than 'const char
*base'
Add return value to 'traverse_tree()' callback
Make 'traverse_trees()' traverse conflicting DF entries in parallel
Move 'unpack_trees()' over to 'traverse_trees()' interface
Fix tree-walking compare_entry() in the presense of --prefix
Add 'const' where appropriate to index handling functions
Make 'unpack_trees()' take the index to work on as an argument
Make 'unpack_trees()' have a separate source and destination index
unpack_trees(): minor memory leak fix in unused destination index
unpack_trees(): fix diff-index regression.
Michal Rokos (1):
autoconf: Test FREAD_READS_DIRECTORIES
Nicolas Pitre (1):
pack-objects: proper pack time stamping with --max-pack-size
Philipp A. Hartmann (1):
git-gui: if a background colour is set, set foreground colour as well
SZEDER Gábor (7):
bash: remove unnecessary conditions when checking for subcommands
bash: refactor searching for subcommands on the command line
bash: add new 'git stash' subcommands
bash: add 'git svn' subcommands and options
bash: use __gitdir when completing 'git rebase' options
bash: fix long option with argument double completion
update 'git rebase' documentation
Samuel Tardieu (1):
"remote update": print remote name being fetched from
Shawn O. Pearce (1):
bash: Remove completion of core.legacyheaders option
Teemu Likonen (1):
bash: Add more long options to be completed with "git --<TAB>"
eric miao (1):
git-gui: translate the remaining messages in zh_cn.po to chinese
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-14 9:11 ` Junio C Hamano
@ 2008-03-23 10:08 ` Junio C Hamano
2008-03-28 1:45 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-23 10:08 UTC (permalink / raw)
To: git
With a few late topics came quite a few regression fixes to make us ready
for -rc1.
* gitk, git-gui and git-p4 have been updated.
* "git gc --auto" annoyance is hopefully reduced away.
* Breakage in automated tag following by git-fetch rewritten in C has
hopefully been fixed.
* Quite a few portability improvements from Solaris porting efforts.
* "git remote show" does not talk about symrefs anymore.
* "git help" updates to plug in more backends.
* "git submodule summary" to show symmetric differences between commits
in submodules.
---
* The 'maint' branch has these fixes since the last announcement.
Bernt Hansen (1):
git-new-workdir: Share SVN meta data between work dirs and the repository
Eric Wong (1):
git-svn: don't blindly append '*' to branch/tags config
Jonas Fonseca (1):
Make man page building quiet when DOCBOOK_XSL_172 is defined
Junio C Hamano (3):
format-patch: generate MIME header as needed even when there is
format.header
rebase -m: do not trigger pre-commit verification
Start draft ReleaseNotes for 1.5.4.5
Linus Torvalds (1):
rev-parse: fix meaning of rev~ vs rev~0.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
git-gui: update russian translation
Brandon Casey (2):
builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto
t/t7003-filter-branch.sh: use test_must_fail rather than '!'
Christian Couder (5):
help: add "man.viewer" config var to use "woman" or "konqueror"
Documentation: help: describe 'man.viewer' config variable
help: implement multi-valued "man.viewer" config option
Documentation: help: explain 'man.viewer' multiple values
help: warn if specified 'man.viewer' is unsupported, instead of erroring
out
Daniel Barkalow (4):
Write diff output to a file in struct diff_options
Tighten refspec processing
Fix t3200 config
Fix tag following
David Aguilar (1):
gitk: Don't show local changes when we there is no work tree
Eyvind Bernhardsen (2):
fast-import: Allow "reset" to delete a new branch without error
fast-import: Document the effect of "merge" with no "from" in a commit
Jeff King (15):
gitk: make autoselect optional
tr portability fixes
t0050: perl portability fix
more tr portability test script fixes
grep portability fix: don't use "-e" or "-q"
remove use of "tail -n 1" and "tail -1"
add test_cmp function for test scripts
t4020: don't use grep -a
t6000lib: tr portability fix
add NO_EXTERNAL_GREP build option
filter-branch: don't use xargs -0
filter-branch: use $SHELL_PATH instead of 'sh'
t9112: add missing #!/bin/sh header
t7505: use SHELL_PATH in hook
t6000lib: re-fix tr portability
Johannes Schindelin (1):
remote show: do not show symbolic refs
Johannes Sixt (1):
git-submodule summary: fix that some "wc" flavors produce leading spaces
Jonas Fonseca (1):
shortlog: do not require to run from inside a git repository
Junio C Hamano (15):
Makefile: DIFF_OBJS is not special at all these days
Makefile: flatten enumeration of headers, objects and programs
Documentation/git-help: typofix
Redo "add test_cmp function for test scripts"
git-gui: Improve directions regarding POT update in po/README
Resurrect git-rerere to contrib/examples
Update draft release notes for 1.5.5
t1000: use "test_must_fail git frotz", not "! git frotz"
git-merge-one-file: fix longstanding stupid thinko
Test: catch if trash cannot be removed
Add tests to catch problems with un-unlinkable symlinks
Fix read-tree not to discard errors
remote.c: Fix overtight refspec validation
gc --auto: raise default auto pack limit from 20 to 50
GIT 1.5.5-rc1
Kevin Ballard (4):
Add --reverse to the git-rev-list usage string
Document the sendemail.smtpserverport config variable
Don't try and percent-escape existing percent escapes in git-svn URIs
Make git-svn tests behave better on OS X
Kristian Høgsberg (1):
wt-status.c: no need for dup() dance anymore
Linus Torvalds (4):
Fix recent 'unpack_trees()'-related changes breaking 'git stash'
Don't update unchanged merge entries
Fix possible Solaris problem in 'checkout_entry()'
Make revision limiting more robust against occasional bad commit dates
Marius Storm-Olsen (1):
git-p4: Optimize the fetching of data from perforce.
Michele Ballabio (4):
gitk: Mark another string for translation
git-gui: update Italian translation
gitk: initial Italian translation
git-gui: remove spurious "fuzzy" attributes in po/it.po
Miklos Vajna (3):
Update Hungarian translation. 100% completed.
git-gui: Updated Hungarian translation (e5fba18)
Documentation/git-merge: document subtree strategy.
Nanako Shiraishi (2):
git-gui: Update Japanese translation
git-gui: Update Japanese translation
Nicolas Pitre (1):
make it easier for people who just want to get rid of 'git gc --auto'
Paul Mackerras (3):
gitk: Only restore window size from ~/.gitk, not position
gitk: Avoid Tcl error when switching views
gitk: Default to using po2msg.sh if msgfmt doesn't grok --tcl, -l and -d
Pekka Kaitaniemi (1):
gitk: Add horizontal scrollbar to the diff view
Peter Karlsson (2):
git-gui: Regenerated po template and merged translations with it
git-gui: updated Swedish translation
Ping Yin (5):
git-submodule summary: code framework
git-submodule summary: show commit summary
git-submodule summary: limit summary size
git-submodule summary: documentation
git-submodule summary: test
Ralf Wildenhues (1):
Improve description of git filter-branch.
Shawn Bohrer (2):
git-p4: Unset P4DIFF environment variable when using 'p4 -du diff'
git-p4: Use P4EDITOR environment variable when set
Shawn O. Pearce (2):
git-gui: Don't translate the special Apple menu
git-gui: Adjusted Japanese translation to updated POT
Yann Dirson (1):
Add an --argscmd flag to get the list of refs to show
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-23 10:08 ` Junio C Hamano
@ 2008-03-28 1:45 ` Junio C Hamano
2008-03-31 8:39 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-28 1:45 UTC (permalink / raw)
To: git
Again with a handful fixes, the most important of which is for regression
introduced in 1.5.4 to "git fetch" (if you are using .git/branches/it to
name your remote repositories, "git fetch it" should update your local
"it" branch but it doesn't since the breakage), maybe we would need
another maintenance branch soon from 'maint'.
With fixes to a handful regressions in the changes that happened during
the 1.5.5 cycle, 'master' is nearling -rc2, which hopefully will happen
soon. There still are one or two topics we may want to merge from 'next',
but at this point both testers and developers are encouraged to switch to
'master' if you have been using 'next' for your real work to catch the
last minute glitches.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Brandon Casey (1):
t/t3800-mktag.sh: use test_must_fail rather than '!'
Daniel Barkalow (2):
Tighten refspec processing
Fix branches file configuration
Guanqun Lu (1):
Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.
Jeff King (1):
Documentation: clarify use of .git{ignore,attributes} versus .git/info/*
Junio C Hamano (2):
git-fetch test: test tracking fetch results, not just FETCH_HEAD
Update draft release notes for 1.5.4.5
* The 'master' branch has these since the last announcement
in addition to the above.
Dirk Süsserott (1):
Documentation: git-tag '-m'/'-F' implies '-a'
Frank Lichtenheld (1):
t9600-cvsimport.sh: set HOME before checking for cvsps availability
Gerrit Pape (1):
imap-send: properly error out if imap.host is not set in config
Guanqun Lu (1):
Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.
Johannes Schindelin (2):
RelNotes: mention checkout/branch's --track option, too
init: show "Reinit" message even in an (existing) empty repository
Johannes Sixt (1):
builtin-remote: Fix missing newline at end of listing of pushed branches
Julian Phillips (1):
Documentation/git-checkout: Update summary to reflect current abilities
Junio C Hamano (3):
refspec: allow colon-less wildcard "refs/category/*"
test_must_fail: 129 is a valid error code from usage()
Update draft release notes for 1.5.5
SZEDER Gábor (1):
Always set *nongit_ok in setup_git_directory_gently()
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-28 1:45 ` Junio C Hamano
@ 2008-03-31 8:39 ` Junio C Hamano
2008-04-04 18:24 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-03-31 8:39 UTC (permalink / raw)
To: git
A handful fixes are in 'master', and a few topics are still in 'next' as I
ran out of time this weekend.
* The 'master' branch has these since the last announcement.
Bryan Donlan (1):
Silence cpio's "N blocks" output when cloning locally
Eric Wong (1):
git-svn: remove redundant slashes from show-ignore
Junio C Hamano (4):
builtin-prune: protect objects listed on the command line
Add corner case tests for diff-index and diff-files
diff-index: careful when inspecting work tree items
diff-files: careful when inspecting work tree items
Marius Storm-Olsen (1):
git-p4: Handle Windows EOLs properly after removal of p4 submit template
handling.
Michele Ballabio (3):
parse-options.c: introduce OPT_DATE
Add tests for git-prune
builtin-prune.c: use parse_options()
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2008-03-31 8:39 ` Junio C Hamano
@ 2008-04-04 18:24 ` Junio C Hamano
2008-04-05 3:13 ` Shawn O. Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2008-04-04 18:24 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement and we are now
at 1.5.5-rc3. The real 1.5.5 hopefully this weekend.
Brandon Casey (2):
mktag.c: improve verification of tagger field and tests
mktag.c: tweak validation of tagger field and adjust test script
Christian Couder (1):
help: Add a missing OPT_END().
Damien Diederen (7):
cvsserver: Respond to the 'editors' and 'watchers' commands
cvsserver: Only print the file part of the filename in status header
cvsserver: Do not include status output for subdirectories if -l is
passed
cvsserver: Add a few tests for 'status' command
cvsserver: Implement update -p (print to stdout)
cvsserver: Add test for update -p
cvsserver: Use the user part of the email in log and annotate results
Johannes Sixt (3):
filter-branch: Test renaming directories in a tree-filter
verify-tag: Clean up the temporary file if gpg cannot be started.
t7004-tag: Skip more tests if gpg is not available.
Jonathan del Strother (1):
git-gui: Add shortcut keys for Show More/Less Context
Josh Elsasser (1):
Allow git-cvsserver database table name prefix to be specified.
Junio C Hamano (2):
Accept git aliases outside a git repository
GIT 1.5.5-rc3
Paolo Bonzini (1):
git-cvsserver: handle change type T
Shawn O. Pearce (1):
git-gui 0.10
Teemu Likonen (1):
Describe the bug in handling filenames with funny characters in 'git add
-i'
veillette@yahoo.ca (1):
filter-branch: Fix renaming a directory in the tree-filter
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2008-04-04 18:24 ` Junio C Hamano
@ 2008-04-05 3:13 ` Shawn O. Pearce
0 siblings, 0 replies; 601+ messages in thread
From: Shawn O. Pearce @ 2008-04-05 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> * The 'master' branch has these since the last announcement and we are now
> at 1.5.5-rc3. The real 1.5.5 hopefully this weekend.
...
> Shawn O. Pearce (1):
> git-gui 0.10
0.10 is a dud on Linux. My master branch has a bug fix, but I'm
considering bringing in Michele's patch before tagging 0.10.1.
So 0.10.1, most likely tagged in a few hours, should be in 1.5.5.
Otherwise Linux users of git-gui will be sort of pissed.
Damn.
--
Shawn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2008-01-14 1:53 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2008-01-14 1:53 UTC (permalink / raw)
To: git
* The 'master' branch has these since v1.5.4-rc3
Eric Wong (1):
git-svn: handle leading/trailing whitespace from svnsync revprops
Jeff King (1):
git-clean: fix off-by-one memory access when given no arguments
Junio C Hamano (1):
builtin-commit.c: remove useless check added by faulty cut and paste
Linus Torvalds (1):
Fix performance regression for partial commits
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git/spearce.git (stable)
@ 2007-10-22 6:11 Shawn O. Pearce
2007-11-01 5:39 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Shawn O. Pearce @ 2007-10-22 6:11 UTC (permalink / raw)
To: git
For those who may be new to the git/spearce.git concept I'm filling
in for Junio and have published a tree on repo.or.cz:
git://repo.or.cz/git/spearce.git
http://repo.or.cz/r/git/spearce.git
------
* The 'maint' branch has these fixes since the last announcement.
Alex Bennee (1):
Ensure we add directories in the correct order
Andrew Clausen (1):
helpful error message when send-pack finds no refs in common.
Brian Gernhardt (1):
cvsserver: Use exit 1 instead of die when req_Root fails.
Gerrit Pape (1):
git-config: print error message if the config file cannot be read
Jeff King (1):
send-pack: respect '+' on wildcard refspecs
Joakim Tjernlund (1):
Improve receive-pack error message about funny ref creation
Johannes Schindelin (3):
Fix setup_git_directory_gently() with relative GIT_DIR &
GIT_WORK_TREE
fix filter-branch documentation
filter-branch: update current branch when rewritten
Julian Phillips (1):
fast-import: Fix argument order to die in file_change_m
Linus Torvalds (4):
git-blame shouldn't crash if run in an unmerged tree
Avoid scary errors about tagged trees/blobs during git-fetch
Fix directory scanner to correctly ignore files without d_type
Fix diffcore-break total breakage
Patrick Welche (1):
Define NI_MAXSERV if not defined by operating system
Ralf Wildenhues (1):
gitk.txt: Fix markup.
Robert Schiele (1):
fixing output of non-fast-forward output of post-receive-email
Shawn O. Pearce (16):
git-gui: Display message box when we cannot find git in $PATH
git-gui: Handle starting on mapped shares under Cygwin
git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
git-gui: Don't crash when starting gitk from a browser session
Correct typos in release notes for 1.5.3.5
Avoid 'expr index' on Mac OS X as it isn't supported
Document additional 1.5.3.5 fixes in release notes
Yet more 1.5.3.5 fixes mentioned in release notes
Avoid invoking diff drivers during git-stash
Further 1.5.3.5 fixes described in release notes
Paper bag fix diff invocation in 'git stash show'
git-gui: Correctly report failures from git-write-tree
git-gui: Handle progress bars from newer gits
git-gui: Don't display CR within console windows
Describe more 1.5.3.5 fixes in release notes
Simon Sasburg (1):
git-gui: Avoid using bold text in entire gui for some fonts
Steffen Prohaska (2):
git-gui: accept versions containing text annotations, like
1.5.3.mingw.1
attr: fix segfault in gitattributes parsing code
* The 'master' branch has these since the last announcement
in addition to the above.
Benoit Sigoure (5):
git-svn: add a generic tree traversal to fetch SVN properties
git-svn: implement git svn create-ignore
git-svn: add git svn propget
git-svn: add git svn proplist
git-svn: simplify the handling of fatal errors
Chris Pettitt (1):
git-p4 support for perforce renames.
Eygene Ryabinkin (1):
git-svn: use "no warnings 'once'" to disable false-positives
Jeff King (3):
git-gc: improve wording of --auto notification
Documentation/git-gc: explain --auto in description
Documentation/git-gc: improve description of --auto
Johannes Schindelin (1):
Deduce exec_path also from calls to git with a relative path
Johannes Sixt (1):
gitk: Do not pick up file names of "copy from" lines
Jonathan del Strother (1):
gitk: Add support for OS X mouse wheel
Junio C Hamano (2):
git-am: make the output quieter.
git-am: fix typo in the previous one.
Linus Torvalds (1):
optimize diffcore-delta by sorting hash entries.
Luke Lu (1):
gitweb: speed up project listing on large work trees by limiting
find depth
Marius Storm-Olsen (1):
Teach core.autocrlf to 'git blame'
Michael Witten (1):
git-cvsexportcommit.perl: git-apply no longer needs --binary
Paul Mackerras (3):
gitk: Check that we are running on at least Tcl/Tk 8.4
gitk: Avoid an error when cherry-picking if HEAD has moved on
gitk: Fix "can't unset prevlines(...)" Tcl error
Ralf Wildenhues (1):
git-cherry-pick: improve description of -x.
René Scharfe (1):
Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
Sam Vilain (1):
gitk: disable colours when calling git log
Shawn O. Pearce (2):
Improved const correctness for strings
Use PRIuMAX instead of 'unsigned long long' in show-index
Simon Hausmann (1):
git-p4: When skipping a patch as part of "git-p4 submit" make sure
we correctly revert to the previous state of the files using
"p4 revert".
koreth@midwinter.com (1):
Add a message explaining that automatic GC is about to start
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-10-22 6:11 What's in git/spearce.git (stable) Shawn O. Pearce
@ 2007-11-01 5:39 ` Junio C Hamano
2007-11-04 3:52 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-01 5:39 UTC (permalink / raw)
To: git
* The 'maint' branch has just produced the 1.5.3.5 release.
* The 'master' branch has these since the last announcement
in addition to what's in 1.5.3.5.
- git-bisect enhancements to support "git bisect skip".
- git-fetch rewritten in C for performance and portability.
- git-svnimport is no more --- use git-svn.
- git-send-pack does not update the tracking ref on the local
side for failed push (needs cherry-picking to 'maint').
- git-rebase does not choke when $GIT_DIR has whitespace in it
(needs cherry-picking to 'maint').
- optimize rename detection.
- comes with updated gitk.
The above list makes me realize that it probably is a good
time to start freezing things for 1.5.4. Tonight's "What's
cooking" will talk about what other topics should graduate to
'master' before that happens.
Alex Riesen (1):
Fix a crash in ls-remote when refspec expands into nothing
Alexandre Julliard (4):
git.el: Fix typo in "Reverted file" message.
git.el: Fix typo in git-update-saved-file error handling.
git.el: Refresh only the changed file marks when marking/unmarking
all.
git.el: Run git-gc --auto after commits.
Benoit Sigoure (1):
core-tutorial: Catch up with current Git
Christian Couder (12):
Test suite: reset TERM to its previous value after testing.
rev-list: implement --bisect-all
rev-list documentation: add "--bisect-all".
Bisect: fix some white spaces and empty lines breakages.
Bisect: implement "bisect skip" to mark untestable revisions.
Bisect: refactor "bisect_write_*" functions.
Bisect: refactor some logging into "bisect_write".
Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
Bisect: add "bisect skip" to the documentation.
Bisect: add a "bisect replay" test case.
Bisect run: "skip" current commit if script exit code is 125.
Bisect: add "skip" to the short usage string.
Dan McGee (1):
Remove outdated references to cogito in documentation
Daniel Barkalow (15):
Refactor http.h USE_CURL_MULTI fill_active_slots().
Make function to refill http queue a callback
Remove obsolete commit-walkers
Modularize commit-walker
Add uploadpack configuration info to remote.
Report information on branches from remote.h
Make fetch-pack a builtin with an internal API
Push code for transport library
Add matching and parsing for fetch-side refspec rules
Add fetch methods to transport library.
Make fetch a builtin
Allow abbreviations in the first refspec to be merged
Restore default verbosity for http fetches.
Remove duplicate ref matches in fetch
Correct handling of upload-pack in builtin-fetch-pack
David Symonds (3):
gitweb: Provide title attributes for abbreviated author names.
gitweb: Refactor abbreviation-with-title-attribute code.
gitweb: Use chop_and_escape_str in more places.
Gerrit Pape (1):
No longer install git-svnimport, move to contrib/examples
Jakub Narebski (1):
gitweb: Fix and simplify "split patch" detection
Jari Aalto (1):
On error, do not list all commands, but point to --help option
Jeff King (2):
send-pack: don't update tracking refs on error
t5516: test update of local refs on push
Jim Meyering (1):
hooks-pre-commit: use \t, rather than a literal TAB in regexp
Johannes Schindelin (6):
Move bundle specific stuff into bundle.[ch]
Add bundle transport
Introduce remove_dir_recursively()
fetch/push: readd rsync support
Fix compilation when NO_CURL is defined
fetch: if not fetching from default remote, ignore default merge
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Junio C Hamano (5):
bundle transport: fix an alloc_ref() call
k.org git toppage: Add link to 1.5.3 release notes.
help: remove extra blank line after "See 'git --help'" message
git-fetch: do not fail when remote branch disappears
RelNotes-1.5.4: describe recent updates
Lars Hjemli (1):
Teach git-pull about --[no-]ff, --no-squash and --commit
Lars Knoll (1):
Speedup scanning for excluded files.
Linus Torvalds (8):
Add 'diffcore.h' to LIB_H
Split out "exact content match" phase of rename detection
Ref-count the filespecs used by diffcore
copy vs rename detection: avoid unnecessary O(n*m) loops
Do linear-time/space rename logic for exact renames
Do exact rename detection regardless of rename limits
Fix ugly magic special case in exact rename detection
Do the fuzzy rename detection limits with the exact renames removed
Miklos Vajna (1):
git-send-email: add a new sendemail.to configuration variable
Nguyễn Thái Ngọc Duy (1):
git-sh-setup.sh: use "git rev-parse --show-cdup" to check for
SUBDIRECTORY_OK
Paul Mackerras (34):
gitk: Establish and use global left-to-right ordering for commits
gitk: Improve the drawing of links to parent lines
gitk: Eliminate diagonal arrows
gitk: Get rid of idrowranges and rowrangelist
gitk: Get rid of idinlist array
gitk: Fix some problems with the display of ids as links
gitk: Get rid of the rowchk array
gitk: Do only the parts of the layout that are needed
gitk: Fix bug causing incorrect ref list contents when switching
view
gitk: Fix bug causing undefined variable error when cherry-picking
gitk: Add a cache for the topology info
gitk: Make it possible to lay out all the rows we have received so
far
gitk: Fix bugs in setting rowfinal
gitk: Get rid of lookingforhead, use commitinterest instead
gitk: Fix bug in generating patches
gitk: Simplify highlighting interface and combine with Find
function
gitk: Fix a couple of bugs
gitk: Add progress bars for reading in stuff and for finding
gitk: Fix the tab setting in the diff display window
gitk: Fix bug causing Tcl error when changing find match type
gitk: Use named fonts instead of the font specification
gitk: Keep track of font attributes ourselves instead of using font
actual
gitk: Add a font chooser
gitk: Fix bug where the last few commits would sometimes not be
visible
gitk: Get rid of the diffopts variable
gitk: Fix Tcl error: can't unset findcurline
gitk: Limit diff display to listed paths by default
gitk: Ensure tabstop setting gets restored by Cancel button
gitk: Integrate the reset progress bar in the main frame
gitk: Use the status window for other functions
gitk: Fix some bugs with path limiting in the diff display
gitk: Fix a couple more bugs in the path limiting
gitk: Simplify the code for finding commits
gitk: Use the UI font for the diff/old version/new version radio
buttons
Pierre Habouzit (3):
Add some fancy colors in the test library when terminal supports
it.
Support a --quiet option in the test-suite.
fast-import.c: fix regression due to strbuf conversion
Shawn O. Pearce (37):
Correct builtin-fetch to handle + in refspecs
Fix off by one bug in reflog messages written by builtin-fetch
Remove unnecessary debugging from builtin-fetch
Remove unused unpacklimit variable from builtin-fetch
Replace custom memory growth allocator with ALLOC_GROW
Simplify fetch transport API to just one function
Refactor index-pack "keep $sha1" handling for reuse
Remove pack.keep after ref updates in git-fetch
Always ensure the pack.keep file is removed by git-fetch
Fix builtin-fetch memory corruption by not overstepping array
Backup the array passed to fetch_pack so we can free items
Properly cleanup in http_cleanup so builtin-fetch does not segfault
Don't bother passing ref log details to walker in builtin-fetch
Cleanup duplicate initialization code in transport_get
Add transport.h to LIB_H as transport.o is in LIB_OBJS
Remove unnecessary 'fetch' argument from transport_get API
Allow builtin-fetch to work on a detached HEAD
Don't configure remote "." to fetch everything to itself
Remove more debugging from builtin-fetch
builtin-fetch: Don't segfault on "fetch +foo"
Don't attempt to merge non-existant remotes in t5515
Correct handling of branch.$name.merge in builtin-fetch
Avoid printing unnecessary warnings during fetch and push
Use 'unsigned:1' when we mean boolean options
Rename remote.uri to remote.url within remote handling internals
Refactor struct transport_ops inlined into struct transport
Always obtain fetch-pack arguments from struct fetch_pack_args
Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
Fix memory leaks when disconnecting transport instances
Cleanup style nit of 'x == NULL' in remote.c
Cleanup unnecessary break in remote.c
Prevent send-pack from segfaulting when a branch doesn't match
Fix 'push --all branch...' error handling
Support 'push --dry-run' for rsync transport
Support 'push --dry-run' for http transport
Avoid scary errors about tagged trees/blobs during git-fetch
Define compat version of mkdtemp for systems lacking it
Väinö Järvelä (1):
Added a test for fetching remote tags when there is not tags.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-01 5:39 ` What's in git.git (stable) Junio C Hamano
@ 2007-11-04 3:52 ` Junio C Hamano
2007-11-08 8:06 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-04 3:52 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Brad King (1):
cvsexportcommit: fix for commits that do not have parents
Jakub Narebski (1):
gitweb: Update config file example for snapshot feature in
gitweb/INSTALL
Jonas Fonseca (1):
Remove escaping of '|' in manpage option sections
Jonathan del Strother (1):
Fixing path quoting in git-rebase
Kristian Høgsberg (1):
Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test
suites.
Ralf Wildenhues (1):
git-clone.txt: Improve --depth description.
Sergei Organov (3):
git-filter-branch.txt: fix a typo.
git-format-patch.txt: fix explanation of an example.
Documentation: quote commit messages consistently.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above. Notable topics are:
- fork-exec removal from MinGW work.
- the first batch of parse-options.
- terse progress display.
Short log follows.
Alex Riesen (2):
Rework make_usage to print the usage message immediately
Do no colorify test output if stdout is not a terminal
Blake Ramsdell (1):
transport.c: squelch a gcc 4.0.1 complaint about an uninitialized
variable
Emil Medve (1):
Fixed a command line option type for builtin-fsck.c
Gerrit Pape (1):
git-diff.txt: add section "output format" describing the diff
formats
James Bowes (1):
gc: use parse_options
Johannes Schindelin (2):
Add tests for parse-options.c
parse-options: Allow abbreviated options when unambiguous
Johannes Sixt (14):
Change git_connect() to return a struct child_process instead of a
pid_t.
Use start_command() in git_connect() instead of explicit fork/exec.
Use start_command() to run content filters instead of explicit
fork/exec.
Use run_command() to spawn external diff programs instead of
fork/exec.
Use start_comand() in builtin-fetch-pack.c instead of explicit
fork/exec.
Have start_command() create a pipe to read the stderr of the child.
upload-pack: Use start_command() to run pack-objects in
create_pack_file().
Add infrastructure to run a function asynchronously.
Use the asyncronous function infrastructure in
builtin-fetch-pack.c.
upload-pack: Move the revision walker into a separate function.
upload-pack: Run rev-list in an asynchronous function.
t0021-conversion.sh: Test that the clean filter really cleans
content.
Avoid a dup2(2) in apply_filter() - start_command() can do it for
us.
Use the asyncronous function infrastructure to run the content
filter.
Jonas Fonseca (1):
Update manpages to reflect new short and long option aliases
Kristian Høgsberg (5):
Enable wt-status output to a given FILE pointer.
Enable wt-status to run against non-standard index file.
Introduce entry point add_interactive and add_files_to_cache
Export rerere() and launch_editor().
Port builtin-add.c to use the new option parser.
Nicolas Pitre (16):
more compact progress display
cope with multiple line breaks within sideband progress messages
pack-objects: no delta possible with only one object in the list
pack-objects.c: fix some global variable abuse and memory leaks
fix const issues with some functions
fix for more minor memory leaks
prune-packed: don't call display_progress() for every file
make struct progress an opaque type
relax usage of the progress API
add throughput to progress display
add throughput display to index-pack
add some copyright notice to the progress display code
add throughput display to git-push
return the prune-packed progress display to the inner loop
make sure throughput display gets updated even if progress doesn't
move
Show total transferred as part of throughput progress
Pierre Habouzit (17):
Add a simple option parser.
parse-options: be able to generate usages automatically
parse-options: make some arguments optional, add callbacks.
Add shortcuts for very often used options.
parse-options: allow callbacks to take no arguments at all.
Make builtin-rm.c use parse_options.
Make builtin-mv.c use parse-options
Make builtin-branch.c use parse_options.
Make builtin-describe.c use parse_options
Make builtin-revert.c use parse_options.
Make builtin-update-ref.c use parse_options
Make builtin-symbolic-ref.c use parse_options.
Make builtin-for-each-ref.c use parse-opts.
Make builtin-fsck.c use parse_options.
Make builtin-count-objects.c use parse_options.
Make builtin-name-rev.c use parse_options.
Make builtin-pack-refs.c use parse_options.
Scott R Parish (7):
"git" returns 1; "git help" and "git help -a" return 0
remove unused/unneeded "pattern" argument of list_commands
"current_exec_path" is a misleading name, use "argv_exec_path"
list_commands(): simplify code by using chdir()
use only the $PATH for exec'ing git commands
include $PATH in generating list of commands for "help -a"
shell should call the new setup_path() to setup $PATH
Shawn O. Pearce (3):
Change 'Deltifying objects' to 'Compressing objects'
Teach prune-packed to use the standard progress meter
Stop displaying "Pack pack-$ID created." during git-gc
Steffen Prohaska (3):
mergetool: use path to mergetool in config var
mergetool.<tool>.path
mergetool: add support for ECMerge
mergetool: avoid misleading message "Resetting to default..."
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-04 3:52 ` Junio C Hamano
@ 2007-11-08 8:06 ` Junio C Hamano
2007-11-08 11:38 ` Pierre Habouzit
2007-11-12 7:06 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-11-08 8:06 UTC (permalink / raw)
To: git
On 'master' front:
- git-p4 in contrib/ has updates. As I cannot test it myself
and did not hear any success/failure stories from the list,
the only way to make sure is to push it out and see if
anybody screams.
- "git lost-found" is going to be deprecated (not removed) in
the next feature release.
- Unspecified clean.requireForce defaults to true; this would
make "git clean" require "-f" by default.
- "git send-email --suppress-from" does not CC yourself even
when your name is on S-o-b: or Cc: lines in the body of the
message.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Ask Bjørn Hansen (1):
When exec() fails include the failing command in the error message
David D Kilzer (2):
RelNotes-1.5.3.5: fix typo
RelNotes-1.5.3.5: fix another typo
Eric Wong (2):
git-svn: fix dcommit clobbering when committing a series of diffs
git-svn: t9114: verify merge commit message in test
Gerrit Pape (3):
git-diff.txt: add section "output format" describing the diff
formats
git-cvsimport: really convert underscores in branch names to dots
with -u
git-daemon: fix remote port number in log entry
Johannes Schindelin (1):
Add Documentation/CodingGuidelines
Junio C Hamano (1):
grep with unmerged index
Marco Costalba (1):
Remove a couple of duplicated include
Mike Hommey (1):
Delay pager setup in git blame
* The 'master' branch has these since the last announcement
in addition to the above.
Benoit Sigoure (1):
git-svn: sort the options in the --help message.
Brian Gernhardt (1):
t3502: Disambiguate between file and rev by adding --
Chris Pettitt (2):
git-p4: Add a helper function to parse the full git diff-tree
output.
git-p4: Detect changes to executable bit and include them in p4
submit.
Daniel Barkalow (1):
Use parseopts in builtin-push
David Symonds (1):
Improve accuracy of check for presence of deflateBound.
Gerrit Pape (4):
git-reset: add -q option to operate quietly
contrib/hooks/post-receive-email: fix typo
contrib/hooks/post-receive-email: reformat to wrap comments at 76
chars
contrib/hooks/post-receive-email: make subject prefix configurable
Heikki Orsila (1):
git-clone: honor "--" to end argument parsing
J. Bruce Fields (1):
errors: "strict subset" -> "ancestor"
Jakub Narebski (9):
gitweb: Always set 'from_file' and 'to_file' in
parse_difftree_raw_line
gitweb: Add 'status_str' to parse_difftree_raw_line output
gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
test
gitweb: Easier adding/changing parameters to current URL
gitweb: Use href(-replay=>1, page=>...) to generate pagination
links
gitweb: Use href(-replay=>1, action=>...) to generate alternate
views
gitweb: Add tests for overriding gitweb config with repo config
gitweb: Read repo config using 'git config -z -l'
gitweb: Use config file for repository description and URLs
Johannes Schindelin (3):
git-reset: do not be confused if there is nothing to reset
Split off the pretty print stuff into its own file
Deprecate git-lost-found
Johannes Sixt (1):
Fix an infinite loop in sq_quote_buf().
Junio C Hamano (6):
revert/cherry-pick: work on merge commits as well
format-patch -s: add MIME encoding header if signer's name requires
so
cherry-pick/revert -m: add tests
test format-patch -s: make sure MIME content type is shown as
needed
clean: require -f to do damage by default
gc: --prune prunes unreferenced objects.
Mike Hommey (5):
Refactor working tree setup
Use setup_work_tree() in builtin-ls-files.c
Don't always require working tree for git-rm
Make git-blame fail when working tree is needed and we're not in
one
Small code readability improvement in show_reference() in
builtin-tag.c
Nicolas Pitre (4):
make the pack index version configurable
pack-objects: get rid of an ugly cast
git-fetch: more terse fetch output
restore fetching with thin-pack capability
Pierre Habouzit (1):
Some better parse-options documentation.
Ralf Wildenhues (1):
Fix minor nits in configure.ac
Shawn Bohrer (1):
Add more tests for git-clean
Simon Sasburg (1):
Make mailsplit and mailinfo strip whitespace from the start of the
input
Steffen Prohaska (1):
Fix comment in strbuf.h to use correct name strbuf_avail()
Steven Grimm (1):
builtin-fetch: Add "-q" as a synonym for "--quiet"
Uwe Kleine-König (1):
send-email: apply --suppress-from to S-o-b and cc-cmd
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-11-08 8:06 ` Junio C Hamano
@ 2007-11-08 11:38 ` Pierre Habouzit
2007-11-12 7:06 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Pierre Habouzit @ 2007-11-08 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Thu, Nov 08, 2007 at 08:06:14AM +0000, Junio C Hamano wrote:
> On 'master' front:
>
> - git-p4 in contrib/ has updates. As I cannot test it myself
> and did not hear any success/failure stories from the list,
> the only way to make sure is to push it out and see if
> anybody screams.
>
> - "git lost-found" is going to be deprecated (not removed) in
> the next feature release.
>
> - Unspecified clean.requireForce defaults to true; this would
> make "git clean" require "-f" by default.
>
> - "git send-email --suppress-from" does not CC yourself even
> when your name is on S-o-b: or Cc: lines in the body of the
> message.
>
> ----------------------------------------------------------------
>
> * The 'maint' branch has these fixes since the last announcement.
[...]
> Pierre Habouzit (1):
> Some better parse-options documentation.
Eeeer isn't there some kind of problem ? This is not in maint, I
believe you swapped 'master' and 'maint' :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-08 8:06 ` Junio C Hamano
2007-11-08 11:38 ` Pierre Habouzit
@ 2007-11-12 7:06 ` Junio C Hamano
2007-11-15 0:20 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-12 7:06 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
stop t1400 hiding errors in tests
Benoit Sigoure (1):
git-send-email: Change the prompt for the subject of the initial
message.
Gerrit Pape (1):
git-mailsplit: with maildirs not only process cur/, but also new/
Jonas Fonseca (1):
instaweb: Minor cleanups and fixes for potential problems
Junio C Hamano (3):
refresh_index_quietly(): express "optional" nature of index writing
better
Makefile: add missing dependency on wt-status.h
Start preparing for 1.5.3.6
Nicolas Pitre (3):
print warning/error/fatal messages in one shot
git-hash-object should honor config variables
fix index-pack with packs >4GB containing deltas on 32-bit machines
Ralf Wildenhues (2):
Avoid a few unportable, needlessly nested "...`...".
Fix sed string regex escaping in module_name.
Sergei Organov (1):
SubmittingPatches: improve the 'Patch:' section of the checklist
Vincent Zanotti (1):
gitweb: correct month in date display for atom feeds
* The 'master' branch has these since the last announcement
in addition to the above.
Gerrit Pape (3):
hooks--update: fix test for properly set up project description
file
hooks--update: decline deleting tags or branches by default, add
config options
contrib/hooks/post-receive-email: remove cruft, $committer is not
used
Johannes Schindelin (4):
parse-options: abbreviation engine fix.
builtin-reset: do not call "ls-files --unmerged"
builtin-reset: avoid forking "update-index --refresh"
builtin-blame: set up the work_tree before the first file access
Johannes Sixt (1):
upload-pack: Use finish_{command,async}() instead of waitpid().
Junio C Hamano (6):
Style: place opening brace of a function definition at column 1
Update draft release notes for 1.5.4
Documentation: lost-found is now deprecated.
Make check-docs target detect removed commands
Documentation: remove documentation for removed tools.
git-commit: a bit more tests
Lars Hjemli (1):
for-each-ref: fix setup of option-parsing for --sort
Michele Ballabio (1):
test-lib.sh: move error line after error() declaration
Nicolas Pitre (1):
add a howto document about corrupted blob recovery
Ralf Wildenhues (1):
git-bisect.sh: Fix sed script to work with AIX and BSD sed.
Sergei Organov (1):
core-tutorial.txt: Fix git-show-branch example and its description
Steffen Prohaska (2):
push: mention --verbose option in documentation
push: teach push to pass --verbose option to transport layer
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-12 7:06 ` Junio C Hamano
@ 2007-11-15 0:20 ` Junio C Hamano
2007-11-17 21:00 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-15 0:20 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Benoit Sigoure (1):
git-svn: prevent dcommitting if the index is dirty.
Christian Couder (1):
for-each-ref: fix off by one read.
Jeff King (1):
git-branch: remove mention of non-existent '-b' option
Jing Xue (1):
replace reference to git-rm with git-reset in git-commit doc
Jonas Fonseca (1):
Documentation: Fix man page breakage with DocBook XSL v1.72
Junio C Hamano (3):
t/t3404: fix test for a bogus todo file.
revert/cherry-pick: allow starting from dirty work tree.
git-clean: honor core.excludesfile
Sergei Organov (2):
core-tutorial.txt: Fix argument mistake in an example.
git-remote.txt: fix typo
Shawn O. Pearce (2):
Fix memory leak in traverse_commit_list
Don't allow fast-import tree delta chains to exceed maximum depth
Wincent Colaiuta (1):
Grammar fixes for gitattributes documentation
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix dependencies of parse-options test program
Andreas Ericsson (1):
Simplify strchrnul() compat code
Björn Steinbrink (3):
git-commit.sh: Fix usage checks regarding paths given when they do
not make sense
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
git-commit: Add tests for invalid usage of -a/--interactive with
paths
Brian Gernhardt (2):
format-patch: Add configuration and off switch for --numbered
format-patch: Test --[no-]numbered and format.numbered
David Symonds (1):
Rearrange git-format-patch synopsis to improve clarity.
Emil Medve (1):
git-stash: Fix listing stashes
Eric Wong (1):
git-svn: support for funky branch and project names over HTTP(S)
Gordon Hopper (1):
git-cvsimport: fix handling of user name when it is not set in
CVSROOT
Johannes Schindelin (2):
rebase: operate on a detached HEAD
rebase: fix "rebase --continue" breakage
Johannes Sixt (2):
git-clean: Fix error message if clean.requireForce is not set.
Fix preprocessor logic that determines the availablity of
strchrnul().
Jonas Fonseca (1):
Documentation: Fix references to deprecated commands
Junio C Hamano (9):
stash: implement "stash create"
rebase: allow starting from a dirty tree.
Revert "rebase: allow starting from a dirty tree."
git-merge: no reason to use cpio anymore
ce_match_stat, run_diff_files: use symbolic constants for
readability
git-add: make the entry stat-clean after re-adding the same
contents
t2200: test more cases of "add -u"
Resurrect git-revert.sh example and add comment to builtin-revert.c
core.excludesfile clean-up
Mike Hommey (2):
Reuse previous annotation when overwriting a tag
Add tests for git tag
Nicolas Pitre (6):
fix display overlap between remote and local progress
sideband.c: ESC is spelled '\033' not '\e' for portability.
make display of total transferred more accurate
remove dead code from the csum-file interface
make display of total transferred fully accurate
nicer display of thin pack completion
Pierre Habouzit (1):
git-fetch: be even quieter.
René Scharfe (5):
Add strchrnul()
--pretty=format: on-demand format expansion
--pretty=format: parse commit message only once
add strbuf_adddup()
--format=pretty: avoid calculating expensive expansions twice
Robin Rosenberg (1):
cvsexportcommit: Add switch to specify CVS workdir
Rémi Vanicat (1):
Make GIT_INDEX_FILE apply to git-commit
Sergei Organov (2):
user-manual.txt: fix a few mistakes
user-manual: minor rewording for clarity.
Shawn O. Pearce (5):
git-fetch: Always fetch tags if the object they reference exists
run-command: Support sending stderr to /dev/null
rev-list: Introduce --quiet to avoid /dev/null redirects
git-fetch: avoid local fetching from alternate (again)
Handle broken vsnprintf implementations in strbuf
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-15 0:20 ` Junio C Hamano
@ 2007-11-17 21:00 ` Junio C Hamano
2007-11-25 20:45 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-17 21:00 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
There are a few candidate fixes for back-porting from the
development series (see "What's cooking" message). I will
include them in 1.5.3.6, probably on or around 20th of this
month.
David Symonds (1):
Improve accuracy of check for presence of deflateBound.
Jeff King (1):
git-send-email: add charset header if we add encoded 'From'
Junio C Hamano (3):
core.excludesfile clean-up
Fix per-directory exclude handing for "git add"
Update draft release notes for 1.5.3.6
Wincent Colaiuta (1):
Fix t9101 test failure caused by Subversion "auto-props"
* The 'master' branch has these since the last announcement
in addition to the above.
Guido Ostkamp (1):
Remove unreachable statements
Jeff King (1):
git-ls-files: add --exclude-standard
Johannes Sixt (1):
refs.c: Remove unused get_ref_sha1()
Junio C Hamano (2):
Fix per-directory exclude handing for "git add"
Update draft release notes for 1.5.4
Mike Hommey (1):
Fix and improve t7004 (git-tag tests)
Sergei Organov (3):
Documentation: customize diff-options depending on particular
command
user-manual.txt: minor clarification.
Documentation: fix git-clone manpage not to refer to itself
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-17 21:00 ` Junio C Hamano
@ 2007-11-25 20:45 ` Junio C Hamano
2007-12-01 2:05 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-11-25 20:45 UTC (permalink / raw)
To: git
There are quite a few backported fixes on 'maint' and it might make
sense to cut 1.5.3.7 soon.
On 'master' front, many topics that have been cooking in 'next' have
graduated. Notably:
- git-bisect learns "skip";
- git-rebase --skip does not need "reset --hard" beforehand;
- git-clean is now in C;
- git-push is much more careful reporting errors and updateing tracking
refs.
- git-push learns --mirror option.
Also contains the 0.9.0 series of git-gui with i18n.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (3):
git-commit.sh: Fix usage checks regarding paths given when they do
not make sense
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
git-commit: Add tests for invalid usage of -a/--interactive with paths
Brian Downing (2):
config: correct core.loosecompression documentation
config: clarify compression defaults
J. Bruce Fields (3):
git-remote.txt: fix example url
user-manual: mention "..." in "Generating diffs", etc.
Documentation: Fix references to deprecated commands
Jeff King (1):
send-email: add transfer encoding header with content-type
Johannes Schindelin (1):
bundle create: keep symbolic refs' names instead of resolving them
Junio C Hamano (10):
format-patch -s: add MIME encoding header if signer's name requires so
test format-patch -s: make sure MIME content type is shown as needed
ce_match_stat, run_diff_files: use symbolic constants for readability
git-add: make the entry stat-clean after re-adding the same contents
t2200: test more cases of "add -u"
grep -An -Bm: fix invocation of external grep command
GIT 1.5.3.6
Make test scripts executable.
Fix sample pre-commit hook
git-checkout: describe detached head correctly
Linus Torvalds (1):
Fix rev-list when showing objects involving submodules
Matthieu Moy (1):
Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
Rémi Vanicat (1):
Make GIT_INDEX_FILE apply to git-commit
Steffen Prohaska (1):
user-manual: Add section "Why bisecting merge commits can be harder ..."
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (4):
More updates and corrections to the russian translation of git-gui
Updated russian translation of git-gui
Add a test checking if send-pack updated local tracking branches
correctly
Update the tracking references only if they were succesfully
updated on remote
Andy Whitcroft (5):
Teach send-pack a mirror mode
git-push: plumb in --mirror mode
Add tests for git push'es mirror mode
git-push: add documentation for the newly added --mirror mode
git-quiltimport.sh fix --patches handling
Anton Gyllenberg (1):
gitview: import only one of gtksourceview and gtksourceview2
Ask Bjørn Hansen (1):
send-email: Don't add To: recipients to the Cc: header
Christian Couder (4):
Bisect reset: remove bisect refs that may have been packed.
Bisect visualize: use "for-each-ref" to list all good refs.
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
Bisect reset: do nothing when not bisecting.
Christian Stimming (12):
Mark strings for translation.
Makefile rules for translation catalog generation and installation.
Add glossary that can be converted into a po file for each
language.
Add glossary translation template into git.
German translation for git-gui
German glossary for translation
git-gui: Add more words to translation glossary
git-gui: Update German glossary according to mailing list
discussion
git-gui: Incorporate glossary changes into existing German
translation
git-gui: Update German translation, including latest glossary
changes
git-gui: Add more terms to glossary.
git-gui: Update German translation
Daniel Barkalow (5):
Miscellaneous const changes and utilities
Build-in peek-remote, using transport infrastructure.
Use built-in send-pack.
Build-in send-pack, with an API for other programs to call.
Build in ls-remote
David D Kilzer (3):
git-svn log: fix ascending revision ranges
git-svn log: include commit log for the smallest revision in a
range
git-svn log: handle unreachable revisions like "svn log"
David D. Kilzer (4):
git-send-email: show all headers when sending mail
git-svn: extract reusable code into utility functions
git-svn info: implement info command
git-svn: info --url [path]
David Reiss (1):
git-svn: Fix a typo and add a comma in an error message in git-svn
David Symonds (2):
git-checkout: Support relative paths containing "..".
git-checkout: Test for relative path use.
Eric Wong (3):
git-svn: add tests for command-line usage of init and clone
commands
t9106: fix a race condition that caused svn to miss modifications
git-svn: allow `info' command to work offline
Guido Ostkamp (1):
Use compat mkdtemp() on Solaris boxes
Harri Ilari Tapio Liusvaara (1):
git-gui: Disambiguate "commit"
Irina Riesen (1):
git-gui: initial version of russian translation
Jakub Narebski (3):
gitweb: Style all tables using CSS
gitweb: Put project README in div.readme, fix its padding
autoconf: Add tests for memmem, strtoumax and mkdtemp functions
Jeff King (11):
more terse push output
receive-pack: don't mention successful updates
send-pack: require --verbose to show update of tracking refs
send-pack: track errors for each ref
send-pack: check ref->status before updating tracking refs
send-pack: assign remote errors to each ref
make "find_ref_by_name" a public function
send-pack: tighten remote error reporting
send-pack: fix "everything up-to-date" message
avoid "defined but not used" warning for fetch_objs_via_walker
send-pack: cluster ref status reporting
Johannes Schindelin (9):
Add po/git-gui.pot
Ignore po/*.msg
git-gui: Deiconify startup wizard so it raises to the top
git-gui: add a simple msgfmt replacement
po2msg: ignore entries marked with "fuzzy"
po2msg: ignore untranslated messages
po2msg: actually output statistics
Close files opened by lock_file() before unlinking.
rebase -i: move help to end of todo file
Johannes Sixt (14):
git-gui: Change main window layout to support wider screens
Give git-am back the ability to add Signed-off-by lines.
t5300-pack-object.sh: Split the big verify-pack test into smaller
parts.
t7501-commit.sh: Not all seds understand option -i
t5302-pack-index: Skip tests of 64-bit offsets if necessary.
Skip t3902-quoted.sh if the file system does not support funny
names.
Use is_absolute_path() in sha1_file.c.
Move #include <sys/select.h> and <sys/ioctl.h> to
git-compat-util.h.
builtin run_command: do not exit with -1.
Allow a relative builtin template directory.
Introduce git_etc_gitconfig() that encapsulates access of
ETC_GITCONFIG.
Allow ETC_GITCONFIG to be a relative path.
fetch-pack: Prepare for a side-band demultiplexer in a thread.
Flush progress message buffer in display().
Junio C Hamano (20):
git-gui po/README: Guide to translators
git-gui: Update Japanese strings (part 2)
scripts: Add placeholders for OPTIONS_SPEC
git-rev-parse --parseopt
git-sh-setup: fix parseopt `eval` string underquoting
send-pack: segfault fix on forced push
git-am: -i does not take a string parameter.
git-bisect: war on "sed"
git-bisect: use update-ref to mark good/bad commits
git-bisect: modernize branch shuffling hack
Draft release notes: fix clean.requireForce description
Update draft release notes for 1.5.4
git-clean: Fix error message if clean.requireForce is not set.
git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY a
bit better
Fix "quote" misconversion for rewrite diff output.
Make test scripts executable.
Addendum to "MaintNotes"
t4119: correct overeager war-on-whitespace
Deprecate peek-remote
Update draft release notes for 1.5.4
Kirill (1):
Updated Russian translation.
Konstantin V. Arkhipov (1):
git-svn's dcommit must use subversion's config
Linus Torvalds (6):
Simplify topo-sort logic
Add "--early-output" log flag for interactive GUI use
Enhance --early-output format
revision walker: mini clean-up
Fix rev-list when showing objects involving submodules
Fix parent rewriting in --early-output
Michele Ballabio (4):
git-gui: remove dots in some UI strings
git-gui: add some strings to translation
git-gui: fix typo in lib/blame.tcl
git-gui: update Italian translation
Mike Hommey (1):
Do git reset --hard HEAD when using git rebase --skip
Miklos Vajna (1):
Hungarian translation of git-gui
Nanako Shiraishi (2):
Japanese translation of git-gui
git-gui: Update Japanese strings
Nicolas Pitre (1):
rehabilitate some t5302 tests on 32-bit off_t machines
Paolo Ciarrocchi (1):
Italian translation of git-gui
Pierre Habouzit (17):
Add a parseopt mode to git-rev-parse to bring parse-options to
shell scripts.
Update git-sh-setup(1) to allow transparent use of git-rev-parse
--parseopt
Migrate git-clean.sh to use git-rev-parse --parseopt.
Migrate git-clone to use git-rev-parse --parseopt
Migrate git-am.sh to use git-rev-parse --parseopt
Migrate git-merge.sh to use git-rev-parse --parseopt
Migrate git-instaweb.sh to use git-rev-parse --parseopt
Migrate git-checkout.sh to use git-rev-parse --parseopt
--keep-dashdash
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Migrate git-repack.sh to use git-rev-parse --parseopt
sh-setup: don't let eval output to be shell-expanded.
parse-options new features.
Use OPT_SET_INT and OPT_BIT in builtin-branch
Use OPT_BIT in builtin-for-each-ref
Use OPT_BIT in builtin-pack-refs
Make the diff_options bitfields be an unsigned with explicit masks.
Reorder diff_opt_parse options more logically per topics.
Shawn Bohrer (2):
Make git-clean a builtin
Teach git clean to use setup_standard_excludes()
Shawn O. Pearce (57):
git-gui: Locate the library directory early during startup
git-gui: Initialize Tcl's msgcat library for internationalization
git-gui: Update po/README as symlink process is not necessary
git-gui: Correct stock message for 'Invalid font specified in %s'
git-gui: Quiet the msgfmt part of the make process
git-gui: Ensure msgfmt failure stops GNU make
git-gui: Mark revision chooser tooltip for translation
git-gui: Localize commit/author dates when displaying them
git-gui: Support context-sensitive i18n
git-gui: Document the new i18n context support
git-gui: Make the tree browser also use lightgray selection
git-gui: Paper bag fix missing translated strings
git-gui: Fix missing i18n markup in push/fetch windows
git-gui: Support native Win32 Tcl/Tk under Cygwin
git-gui: Refactor some UI init to occur earlier
git-gui: Allow users to choose/create/clone a repository
git-gui: Avoid console scrollbars unless they are necessary
git-gui: Don't bother showing OS error message about hardlinks
git-gui: Keep the UI responsive while counting objects in clone
git-gui: Copy objects/info/alternates during standard clone
git-gui: Don't delete console window namespaces too early
git-gui: Don't delete scrollbars in console windows
git-gui: Switch the git-gui logo to Henrik Nyh's logo
git-gui: Make the status bar easier to read in the setup wizard
git-gui: Use Henrik Nyh's git logo icon on Windows systems
git-gui: Support a native Mac OS X application bundle
git-gui: Refer to ourselves as "Git Gui" and not "git-gui"
git-gui: Allow forced push into remote repository
git-gui: Refactor Henrik Nyh's logo into its own procedure
git-gui: Refactor about dialog code into its own module
git-gui: Include our Git logo in the about dialog
git-gui: Use progress meter in the status bar during index updates
git-gui: Consolidate the Fetch and Push menus into a Remote menu
git-gui: Bind Cmd-, to Preferences on Mac OS X
git-gui: Shorten the staged/unstaged changes title bar text
git-gui: Updated po strings based on current sources
git-gui: Move load_config procedure below git-version selection
git-gui: Refactor git-config --list parsing
git-gui: Support LFs embedded in config file values
git-gui: Change repository browser radio buttons to hyperlinks
git-gui: Offer repository management features in menu bar
git-gui: Fix bind errors when switching repository chooser panels
git-gui: Disable the text widget in the repository chooser
git-gui: Bind n/c/o accelerators in repository chooser
git-gui: Ensure copyright message is correctly read as UTF-8
git-gui: Use proper Windows shortcuts instead of bat files
git-gui: Support cloning Cygwin based work-dirs
git-gui: Collapse $env(HOME) to ~/ in recent repositories on
Windows
git-gui: Honor a config.mak in git-gui's top level
git-gui: Paper bag fix the global config parsing
git-gui: Make sure we get errors from git-update-index
git-gui: Protect against bad translation strings
git-gui: Allow users to set font weights to bold
Reteach builtin-ls-remote to understand remotes
git-gui: Bind Meta-T for "Stage To Commit" menu action
Fix warning about bitfield in struct ref
git-gui 0.9.0
Shun Kei Leung (1):
git-p4: Fix typo in --detect-labels
Simon Hausmann (1):
git-p4: Fix direct import from perforce after fetching changes
through git from origin
Steffen Prohaska (4):
git-gui: add directory git-gui is located in to PATH (on Windows)
git-gui: set NO_MSGFMT to force using pure tcl replacement in
msysgit
git-gui: add mingw specific startup wrapper
git-gui: offer a list of recent repositories on startup
Thomas Harning (1):
git-merge-ours: make it a builtin.
Wincent Colaiuta (3):
Further clarify clean.requireForce changes
Authenticate only once in git-send-email
Refactor patch_update_cmd
Xudong Guan (2):
Initial Chinese translation for git-gui
git-gui: Added initial version of po/glossary/zh_cn.po
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-11-25 20:45 ` Junio C Hamano
@ 2007-12-01 2:05 ` Junio C Hamano
2007-12-04 8:43 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-01 2:05 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
J. Bruce Fields (4):
user-manual: define "branch" and "working tree" at start
user-manual: failed push to public repository
user-manual: clarify language about "modifying" old commits
user-manual: recovering from corruption
Jan Hudec (1):
Improve description of git-branch -d and -D in man page.
Jeff King (4):
Add basic cvsimport tests
cvsimport: use rev-parse to support packed refs
cvsimport: miscellaneous packed-ref fixes
cvsimport: fix usage of cvsimport.module
Johannes Schindelin (1):
Replace the word 'update-cache' by 'update-index' everywhere
Johannes Sixt (1):
t7003-filter-branch: Fix test of a failing --msg-filter.
Junio C Hamano (1):
scripts: do not get confused with HEAD in work tree
* The 'master' branch has these since the last announcement
in addition to the above.
André Goddard Rosa (2):
Print the real filename that we failed to open.
Error out when user doesn't have access permission to the repository
Jakub Narebski (1):
Add config_int() method to the Git perl module
Jeff King (1):
Revert "t5516: test update of local refs on push"
Johannes Schindelin (4):
filter-branch: fix dirty way to provide the helpers to commit filters
git checkout's reflog: even when detaching the HEAD, say from where
bash completion: add diff options
receive-pack: allow deletion of corrupt refs
Junio C Hamano (3):
revert/cherry-pick: do not mention the original ref
dir.c: minor clean-up
per-directory-exclude: lazily read .gitignore files
Linus Torvalds (2):
Fix a pathological case in git detecting proper renames
Fix a pathological case in git detecting proper renames
Pascal Obry (1):
git-stash: do not get fooled with "color.diff = true"
Steffen Prohaska (2):
Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
sha1_file.c: Fix size_t related printf format warnings
Wincent Colaiuta (1):
Fix typo in draft 1.5.4 release notes
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-12-01 2:05 ` Junio C Hamano
@ 2007-12-04 8:43 ` Junio C Hamano
2007-12-05 10:57 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-04 8:43 UTC (permalink / raw)
To: git
Nothing exciting on 'maint' since 1.5.3.7.
On the 'master' front, we will soon be in feature freeze for 1.5.4.
Many topics that have been cooking in 'next' has been pushed out. This
round it is a rather large batch but hopefully it will not destabilize
it too much. Knock wood.
* "git pull --rebase" is a different way to integrate what you fetched
into your current branch.
* "git fast-export" produces datastream that can be fed to fast-import
to reproduce the history recorded in a git repository.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git commit --allow-empty" allows you to create a single-parent
commit that records the same tree as its parent, overriding the usual
safety valve.
* "git stash random-text" does not create a new stash anymore. It was
a UI mistake. Use "git stash save random-text", or "git stash"
(without extra args) for that.
* HTTP proxy can be specified per remote repository using
remote.*.proxy configuration, or global http.proxy configuration
variable.
* "git rebase -i" also triggers rerere to help you repeated merges.
* "git prune --expire <time>" can exempt young loose objects from
getting pruned.
* "git branch --contains <commit>" can list branches that are
descendants of a given commit.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Jeff King (1):
t9600: test cvsimport from CVS working tree
Junio C Hamano (2):
Fix typo in t4008 test title
GIT 1.5.3.7
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Whitcroft (1):
git-svn: add support for pulling author from From: and Signed-off-by:
Carlos Rica (1):
Make builtin-tag.c use parse_options.
Christian Couder (2):
Documentation: add a new man page for "git-help"
Trace and quote with argv: get rid of unneeded count argument.
David D. Kilzer (1):
git-svn: Remove unnecessary Git::SVN::Util package
David Symonds (1):
Mention that git-rm can be an appropriate resolution as well as git-add.
Denis Cheng (1):
gitweb: the commitdiff is very commonly used, it's needed on search page,
too
Gustaf Hendeby (1):
git-svn now reads settings even if called in subdirectory
Jakub Narebski (1):
gitweb: Update and improve gitweb/README file
Jeff King (2):
git-tag: test that -s implies an annotated tag
Enable rewrite as well as rename detection in git-status
Johannes Schindelin (7):
Replace instances of export VAR=VAL with VAR=VAL; export VAR
Teach 'git pull' about --rebase
rebase -i: give rerere a chance
Add "--expire <time>" option to 'git prune'
Add 'git fast-export', the sister of 'git fast-import'
fast-export: rename the signed tag mode 'ignore' to 'verbatim'
Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0
Johannes Sixt (1):
git-commit: Allow to amend a merge commit that does not change the tree
Junio C Hamano (17):
Move gitk to its own subdirectory
git-branch --contains=commit
git-branch --contains: doc and test
builtin-tag: accept and process multiple -m just like git-commit
"git-tag -s" should create a signed annotated tag
"color.diff = true" is not "always" anymore.
git-config --get-color: get configured color
Update draft release notes for 1.5.4
Resurrect peek-remote
Consolidate command list to one.
Update draft release notes for 1.5.4
rename: Break filepairs with different types.
git-am: catch missing author date early.
git-commit --allow-empty
git-commit documentation: fix unfinished sentence.
Add git-fast-export to list of commands.
Update draft release notes for 1.5.4
Kevin Leung (1):
git-stash: Display help message if git-stash is run with wrong
sub-commands
Pierre Habouzit (1):
parse-options: Allow to hide options from the default usage.
Robert Schiele (1):
install-sh from automake does not like -m without delimiting space
Sam Vilain (2):
Allow HTTP proxy to be overridden in config
Add remote.<name>.proxy
Steven Grimm (1):
git-svn: Don't create a "master" branch every time rebase is run
Theodore Ts'o (2):
Make the list of common commands more exclusive
Remove hint to use "git help -a"
Vineet Kumar (1):
git-svn: add a show-externals command.
Wincent Colaiuta (1):
revert/cherry-pick: Allow overriding the help text by the calling
Porcelain
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-12-04 8:43 ` Junio C Hamano
@ 2007-12-05 10:57 ` Junio C Hamano
2007-12-07 9:50 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-05 10:57 UTC (permalink / raw)
To: git
I haven't tagged the tip of 'master' as -rc0 yet, this has more than 80%
of it. Graduated to 'master' tonight are:
* Wincent's "git add -p"
* "git commit in C" by Kristian and others
* Steffen Prohaska's clean-up of push/fetch refspec handling.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Do not generate full commit log message if it is not going to be used
Simplify crud() in ident.c
H.Merijn Brand (1):
Do not rely on the exit status of "unset" for unset variables
Jakub Narebski (1):
contrib: Make remotes2config.sh script more robust
Jeff King (3):
git-commit: clean up die messages
quote_path: fix collapsing of relative paths
t9600: require cvsps 2.1 to perform tests
Johannes Schindelin (8):
launch_editor(): read the file, even when EDITOR=:
builtin-commit: fix reflog message generation
git status: show relative paths when run in a subdirectory
builtin-commit: fix --signoff
builtin-commit --s: add a newline if the last line was not a S-o-b
builtin-commit: resurrect behavior for multiple -m options
builtin-commit: Add newline when showing which commit was created
Replace "runstatus" with "status" in the tests
Junio C Hamano (15):
file_exists(): dangling symlinks do exist
builtin-commit: do not color status output shown in the message template
builtin-commit: run commit-msg hook with correct message file
Export three helper functions from ls-files
Fix add_files_to_cache() to take pathspec, not user specified list of
files
builtin-commit: fix partial-commit support
git-add -i: allow multiple selection in patch subcommand
Add a few more tests for git-commit
builtin-add: fix command line building to call interactive
add -i: Fix running from a subdirectory
Fix --signoff in builtin-commit differently.
git-commit: Allow to amend a merge commit that does not change the tree
git-commit --allow-empty
Documentation/git.txt: typofix
t5510: add a bit more tests for fetch
Kristian Høgsberg (10):
Add testcase for amending and fixing author in git commit.
Export launch_editor() and make it accept ':' as a no-op editor.
Port git commit to C.
builtin-commit: Refresh cache after adding files.
Call refresh_cache() when updating the user index for --only commits.
builtin-commit: Clean up an unused variable and a debug fprintf().
t7501-commit: Add test for git commit <file> with dirty index.
builtin-commit: Include the diff in the commit message when verbose.
Fix off-by-one error when truncating the diff out of the commit message.
Use a strbuf for copying the command line for the reflog.
Pascal Obry (1):
Set OLD_ICONV on Cygwin.
Pierre Habouzit (1):
builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
Ralf Wildenhues (1):
Document all help keys in "git add -i" patch mode.
Shawn Bohrer (1):
Make git status usage say git status instead of git commit
Shawn O. Pearce (1):
Remove git-status from list of scripts as it is builtin
Steffen Prohaska (4):
push: support pushing HEAD to real branch name
add refname_match()
push: use same rules as git-rev-parse to resolve refspecs
refactor fetch's ref matching to use refname_match()
Wincent Colaiuta (6):
Teach builtin-add to pass multiple paths to git-add--interactive
Add path-limiting to git-add--interactive
Add "--patch" option to git-add--interactive
Highlight keyboard shortcuts in git-add--interactive
add -i: allow prefix highlighting for "Add untracked" as well.
git-add -i: add help text for list-and-choose UI
İsmail Dönmez (1):
gitweb: use Perl built-in utf8 function for UTF-8 decoding.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-12-05 10:57 ` Junio C Hamano
@ 2007-12-07 9:50 ` Junio C Hamano
2007-12-09 10:32 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-12-07 9:50 UTC (permalink / raw)
To: git
Heavy merges to 'master' continues. We are almost there for -rc0.
Merged to 'master' are:
* Colorized "add -i" (Dan Zwell)
* Talk more about diff options in "git log" documentation (Miklos)
* git-gui 0.9.1 preview
* Make cvsserver act more like receive-pack (Michael Witten)
* "git-clean <paths>" limits the damage to named paths
* Use right Perl in Documentation/Makefile
Also people's favorite topic "squelching compilation warnings for iconv"
is included.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
David Symonds (1):
Change from using email.com to example.com as example domain, as per RFC
2606.
Junio C Hamano (2):
git grep shows the same hit repeatedly for unmerged paths
git-am -i: report rewritten title
Nguyễn Thái Ngọc Duy (3):
Add missing inside_work_tree setting in setup_git_directory_gently
Do check_repository_format() early
Do check_repository_format() early (re-fix)
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Björn Steinbrink (1):
git config: Don't rely on regexec() returning 1 on non-match
Brian M. Carlson (1):
git-gui: Reorder msgfmt command-line arguments
Christian Stimming (2):
Update git-gui.pot with latest (few) string additions and changes.
Update German translation. 100% completed.
Jakub Narebski (1):
autoconf: Add test for OLD_ICONV (squelching compiler warning)
Jeff King (1):
t7300: add test for clean with wildcard pathspec
Johannes Sixt (2):
git-gui: Improve the application icon on Windows.
for-each-ref: Fix quoting style constants.
Junio C Hamano (12):
Run the specified perl in Documentation/
git-cvsserver runs hooks/post-update
Revert "git-am: catch missing author date early."
Documentation: color.* = true means "auto"
git config --get-colorbool
Color support for "git-add -i"
git-clean: Honor pathspec.
config --get-colorbool: diff.color is a deprecated synonym to color.diff
hg-to-git: handle an empty dir in hg.
do not discard status in fetch_refs_via_pack()
git-status documentation: mention subdirectory behaviour
Update draft release notes to 1.5.4
Kristian Høgsberg (1):
Rewrite builtin-fetch option parsing to use parse_options().
Matthias Kestenholz (1):
Documentation: add --patch option to synopsis of git-add
Michael Witten (1):
git-cvsserver runs hooks/post-receive
Michele Ballabio (2):
git-gui: fix a typo in lib/commit.tcl
git-gui: update it.po and glossary/it.po
Miklos Vajna (2):
Include diff options in the git-log manpage
Update Hungarian translation. 100% completed.
Nanako Shiraishi (1):
Update ja.po for git-gui
Robert Schiele (1):
git-gui: install-sh from automake does not like -m755
Wincent Colaiuta (1):
Silence iconv warnings on Leopard
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-12-07 9:50 ` Junio C Hamano
@ 2007-12-09 10:32 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-12-09 10:32 UTC (permalink / raw)
To: git
One more topic remains in 'next' before 1.5.4-rc0 where "bugfix only"
freeze period begins. We have a handful regression fixes on 'master'
from the fallout from massive C-rewrite during this cycle.
People still following 'next' are requested to switch to 'master', and
spare a bit more time on finding and fixing regressions there instead of
coming up with new topics from now on.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Jim Meyering (1):
config.c:store_write_pair(): don't read the byte before a malloc'd
buffer.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (3):
wt-status.c:quote_path(): convert empty path to "./"
add status.relativePaths config variable
git-status: documentation improvements
Junio C Hamano (13):
War on whitespace: first, a bit of retreat.
git-diff: complain about >=8 consecutive spaces in initial indent
core.whitespace: add test for diff whitespace error highlighting
builtin-apply: rename "whitespace" variables and fix styles
builtin-apply: teach whitespace_rules
core.whitespace: documentation updates.
Use gitattributes to define per-path whitespace rule
git-bisect visualize: work in non-windowed environments better
mailmap: fix bogus for() loop that happened to be safe by accident
shortlog: code restructuring and clean-up
ls-remote: resurrect pattern limit support
Fix commit-msg hook to allow editing
Re-fix "builtin-commit: fix --signoff"
Nicolas Pitre (3):
pack-objects: fix delta cache size accounting
pack-objects: reverse the delta search sort list
pack-objects: fix threaded load balancing
Pini Reznik (1):
Open external merge tool with original file extensions for all three
files
Sergei Organov (1):
Let git-help prefer man-pages installed with this version of git
Wincent Colaiuta (4):
Teach "git add -i" to colorize whitespace errors
Allow --no-verify to bypass commit-msg hook
Documentation: fix --no-verify documentation for "git commit"
Add tests for pre-commit and commit-msg hooks
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-09-06 8:52 Junio C Hamano
[not found] ` <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-09-06 8:52 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since v1.5.3.1
Dmitry V. Levin (1):
Makefile: Add cache-tree.h to the headers list
Junio C Hamano (1):
git-apply: do not read past the end of buffer
Shawn O. Pearce (3):
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
Cleanup unnecessary file modifications in t1400-update-ref
Include a git-push example for creating a remote branch
* The 'master' branch has these since v1.5.3 in addition to the
above.
Carlos Rica (1):
Function for updating refs.
Douglas Stockwell (1):
send-email: Add support for SSL and SMTP-AUTH
Junio C Hamano (1):
Start 1.5.4 cycle
Simon Hausmann (8):
git-p4: Always call 'p4 sync ...' before submitting to Perforce.
git-p4: After submission to p4 always synchronize from p4 again
(into refs/remotes). Whether to rebase HEAD or not is still
left as question to the end-user.
git-p4: Cleanup; moved the code for getting a sorted list of p4
changes for a list of given depot paths into a standalone
method.
git-p4: Cleanup; moved the code to import a list of p4 changes
using fast-import into a separate member function of P4Sync.
git-p4: Cleanup; Turn self.revision into a function local variable
(it's not used anywhere outside the function).
git-p4: Cleanup; moved the code for the initial #head or revision
import into a separate function, out of P4Sync.run.
git-p4: Cleanup; moved the (duplicated) code for turning a branch
into a git ref (for example foo ->
refs/remotes/p4/<project>/foo) into a separate method.
git-p4: Added support for automatically importing newly appearing
perforce branches.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-08-23 0:37 Junio C Hamano
2007-08-24 0:28 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-08-23 0:37 UTC (permalink / raw)
To: git
Many documentation updates, fast-import fixes and enhancements,
updated gitk.
Hopefully we can do the final without another -rc sometime early
next week.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (3):
Fix whitespace in "Format of STDIN stream" of fast-import
Avoid using va_copy in fast-import: it seems to be unportable.
Fix git-remote for ActiveState Perl
Alexandre Julliard (1):
git.el: Avoid a lisp error when there's no current branch (detached
HEAD).
Arjen Laarhoven (2):
gitk: Make the date/time display configurable
t1301-shared-repo.sh: fix 'stat' portability issue
Brian Downing (1):
Clarify actual behavior of 'git add' and ignored files
Brian Gernhardt (1):
Minor clarifications to git-filter-branch usage and doc
Dave Watson (1):
Fix misspelling of 'suppress' in docs
Eric Wong (1):
git-svn: update documentation with CAVEATS section
Johannes Sixt (1):
gitk: Handle 'copy from' and 'copy to' in diff headers.
Junio C Hamano (5):
Documentation/git-rebase: fix an example
Clean-up read-tree error condition.
fast-import pull request
git clone: do not issue warning while cloning locally across
filesystems
GIT 1.5.3-rc6
Lars Hjemli (1):
git-submodule: re-enable 'status' as the default subcommand
Linus Torvalds (2):
Make thin-pack generation subproject aware.
Take binary diffs into account for "git rebase"
Lukas Sandström (1):
Add the word reflog to
Documentation/config.txt:core.logAllRefUpdates
Mark Levedahl (1):
git-completion.bash - add support for git-bundle
Matthieu Moy (1):
Add and document a global --no-pager option for git.
Mike Hommey (1):
Clarify commit-tree documentation
Paul Mackerras (3):
gitk: Fix warning when removing a branch
gitk: Fix bug in fix for warning when removing a branch
gitk: Add a window to list branches, tags and other references
Quy Tonthat (1):
Fix breakage in git-rev-list.txt
René Scharfe (1):
Documentation: update tar.umask default
Sean Estabrooks (2):
Fix small typo in git send-email man page.
Reset terminal attributes when terminating git send-email
Shawn O. Pearce (13):
git-gui: Avoid Tcl error in popup menu on diff viewer
Actually allow TAG_FIXUP branches in fast-import
Use handy ALLOC_GROW macro in fast-import when possible
Teach fast-import to ignore lines starting with '#'
Make trailing LF following fast-import `data` commands optional
Make trailing LF optional for all fast-import commands
Allow frontends to bidirectionally communicate with fast-import
Generate crash reports on die in fast-import
Include recent command history in fast-import crash reports
Correct documentation of 'reflog show' to explain it shows HEAD
Don't allow combination of -g and --reverse as it doesn't work
Fix new-workdir (again) to work on bare repositories
Suggest unsetting core.bare when using new-workdir on a bare
repository
Stefan Sperling (1):
Document -u option in git-svnimport man page
Steffen Prohaska (1):
gitk: Let user easily specify lines of context in diff view
Steven Grimm (1):
Document what the stage numbers in the :$n:path syntax mean.
Väinö Järvelä (1):
git-gui: Added support for OS X right click
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-08-11 8:41 Junio C Hamano
2007-08-11 9:32 ` David Kastrup
2007-08-16 5:02 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-11 8:41 UTC (permalink / raw)
To: git
I thought we were pretty in good shape and in a nice and quiet
freeze period.
Until a few days ago.
Then suddenly, flurry of activity happened. A few performance
issues were raised and fixed:
* "git-status" on a huge tree was way suboptimal and found to
have unnecessary O(n^2) codepath. Fixing this also sped up
"git-diff --cached";
* "git-commit paths..." had a few other bottlenecks. "git-add
--stdin" was one of them;
* In addition, Linus optimized all three cases of "git
read-tree" that had the same inefficiency;
* "git-bundle create" had a stupid "one-byte-at-a-time" loop
that was unnecessary.
Also one of the new features in 1.5.3, GIT_WORK_TREE, was found
to be not-quite-ready. I think the few commits during the last
couple of days should finally make it ready.
I have resisted merging any new features that were not present
in 1.5.3-rc1, but it appears that we would need to have a few
more -rc rounds before the final _anyway_, so I went into a
merge-binge. A couple of well done topics from the next branch
are now in master:
* Carlos's "builtin tag" series;
* David's "format documentation in info format as well" series;
Expect the tip of 'master' to be tagged v1.5.3-rc5 and let's
hope it to be the last -rc before 1.5.3 final.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix filehandle leak in "git branch -D"
Brian Downing (1):
cvsserver: Fix for work trees
Carlos Rica (3):
Make git tag a builtin.
builtin-tag.c: Fix two memory leaks and minor notation changes.
Make verify-tag a builtin.
David Kastrup (4):
Documentation/git-commit.txt: correct bad list formatting.
Add support for an info version of the user manual
INSTALL: explain info installation and dependencies.
Documentation/Makefile: remove cmd-list.made before redirecting to
it.
Johannes Schindelin (3):
launch_editor(): Heed GIT_EDITOR and core.editor settings
Teach "git stripspace" the --strip-comments option
Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE
is unset
Junio C Hamano (9):
git-clone: aggressively optimize local clone behaviour.
Reorder the list of commands in the manual.
Fix formatting of git-blame documentation.
Fix an illustration in git-rev-parse.txt
tweak manpage formatting
Revert "tweak manpage formatting"
Optimize "diff --cached" performance.
allow git-bundle to create bottomless bundle
allow git-bundle to create bottomless bundle
Linus Torvalds (7):
connect: accept file:// URL scheme
Start moving unpack-trees to "struct tree_desc"
Fix "git commit directory/" performance anomaly
Move old index entry removal from "unpack_trees()" into the
individual functions
Optimize the common cases of git-read-tree
Optimize the two-way merge of git-read-tree too
Optimize the three-way merge of git-read-tree
Mark Levedahl (2):
builtin-bundle.c - use stream buffered input for rev-list
builtin-bundle - use buffered reads for bundle header
Shawn O. Pearce (3):
Teach update-paranoid how to store ACLs organized by groups
Teach the update-paranoid to look at file differences
Use the empty tree for base diff in paranoid-update on new branches
Simon Hausmann (2):
git-p4: Fix support for symlinks.
git-p4: Fix git-p4 submit to include only changed files in the
perforce submit template.
Steve Hoelzer (2):
git-stash documentation: stash numbering starts at zero, not one
git-stash documentation: add missing backtick
Steven Grimm (1):
Add a note about the index being updated by git-status in some
cases
Uwe Kleine-König (2):
send-email: rfc822 forbids using <address@domain> without a
non-empty "phrase"
send-email: get all the quoting of realnames right
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-08-11 8:41 Junio C Hamano
@ 2007-08-11 9:32 ` David Kastrup
2007-08-16 5:02 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: David Kastrup @ 2007-08-11 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> I thought we were pretty in good shape and in a nice and quiet
> freeze period.
>
> Until a few days ago.
>
> Then suddenly, flurry of activity happened. A few performance
> issues were raised and fixed:
The fix to git-filter-branch I posted is tested and obviously
necessary (without it, git-filter-branch will only work if GIT_DIR is
set previously to calling it).
Also documentation and usage of git-filter-branch are out of kilter,
the given examples for wiping a file from history don't work,
specifing the refs to work on reacts impredictably (it is not clear
what gets accepted and what not, and one seemingly has to always
specify "HEAD" which is basically ignored).
Could you ask Dscho to consider adding cases based on the
documentation to the test suite? That should help weed out the worst
discrepances.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-08-11 8:41 Junio C Hamano
2007-08-11 9:32 ` David Kastrup
@ 2007-08-16 5:02 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-16 5:02 UTC (permalink / raw)
To: git
Maintenance release 1.5.2.5 is out, so that a fix for "add -u"
breakage can be propagated out to a released version without
waiting for the 1.5.3 final.
The 'master' branch has a few more fixes since -rc5. Notable
are:
- fix "add -u" (in 'maint');
- fix "read-tree -m base1 base2 ours theirs";
- fix "clone --bare";
- teach "git apply" to handle submodule patches;
I would like to ask subsystem people to give a pull request
destined for the 1.5.3 final by the end of the week, so that we
can do -rc6 and make it the last rc in this cycle.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (2):
Fix "git add -u" data corruption.
GIT 1.5.2.5
Salikh Zakirov (1):
git-add -u paths... now works from subdirectory
* The 'master' branch has these since the last announcement
in addition to the above.
Alberto Bertogli (1):
Allow git-svnimport to take "" as the trunk directory.
Alex Riesen (2):
gitk: Continue and show error message in new repos
gitk: Show an error and exit if no .git could be found
Alexandre Julliard (3):
git.el: Add support for interactive diffs.
git.el: Always set the current directory in the git-diff buffer.
git-add: Add support for --refresh option.
Brian Downing (1):
Add read_cache to builtin-check-attr
Brian Gernhardt (1):
Fix t5701-clone-local for white space from wc
David Kastrup (2):
git-sh-setup.sh: make GIT_DIR absolute
Add a test for git-commit being confused by relative GIT_DIR
Eric Wong (1):
git-svn: fix log with single revision against a non-HEAD branch
Junio C Hamano (10):
t3404: fix "fake-editor"
builtin-bundle create - use lock_file
git-diff: squelch "empty" diffs
merge-recursive: do not rudely die on binary merge
attr.c: refactoring
attr.c: read .gitattributes from index as well.
GIT 1.5.3-rc5
Fix read-tree merging more than 3 trees using 3-way merge
Update documentation links for older releases.
git-clone: allow --bare clone
Luiz Fernando N. Capitulino (3):
Avoid ambiguous error message if pack.idx header is wrong
Introduces xmkstemp()
Use xmkstemp() instead of mkstemp()
Marco Costalba (1):
Add --log-size to git log to print message size
Mark Levedahl (3):
gitk: Enable selected patch text on Windows
gitk: Handle MouseWheel events on Windows
t3902 - skip test if file system doesn't support HT in names
Nicolas Pitre (1):
pack-objects: remove bogus arguments to delta_cacheable()
Paul Mackerras (4):
gitk: Add a context menu for file list entries
gitk: Fix bug causing the "can't unset idinlist(...)" error
gitk: Fix bug introduced in commit 67a4f1a7
gitk: Fix bug causing Tcl error when updating graph
Reece H. Dunn (1):
git-p4: Fix the sorting of changelists when cloning a Perforce
repository.
René Scharfe (3):
diff: don't run pager if user asked for a diff style exit code
diff: squelch empty diffs even more
path-list.c: always free strdup'ed paths
Steffen Prohaska (1):
Improved hint on how to set identity
Sven Verdoolaege (1):
git-apply: apply submodule changes
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-05-13 22:30 Junio C Hamano
2007-05-17 0:21 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-13 22:30 UTC (permalink / raw)
To: git
We accumulated quite a few fixes on 'maint' since v1.5.1.4, and
they apply to 'master' as well.
Things that are not in 'master' yet but are scheduled for v1.5.2
final are a performance bug fix for cvsexportcommit (in 'pu')
and user manual updates to add a bit of source code tour, which
hopefully would happen by the middle of the week, and then we
will have the final v1.5.2 next weekend.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.1.4
Alex Riesen (1):
Allow fetching references from any namespace
Eric Wong (4):
git-svn: don't drop the username from URLs when dcommit is run
git-svn: clean up caching of SVN::Ra functions
git-svn: fix segfaults due to initial SVN pool being cleared
git-svn: don't attempt to minimize URLs by default
Jan Hudec (1):
Updated documentation of hooks in git-receive-pack.
Jari Aalto (1):
SPECIFYING RANGES typo fix: it it => it is
Junio C Hamano (4):
git-clone: don't get fooled by $PWD
.mailmap: add some aliases
checkout: allow detaching to HEAD even when switching to the tip of a branch
git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.
Marco Costalba (1):
Fix an unmatched comment end in arm/sha1_arm.S
Matthieu Castet (1):
Remove stale non-static-inline prototype for tree_entry_extract()
Quy Tonthat (1):
RPM spec: include files in technical/ to package.
Richard P. Curnow (2):
Fix documentation of tag in git-fast-import.txt
Fix documentation of tag in git-fast-import.txt
Shawn O. Pearce (1):
Properly handle '0' filenames in import-tars
Steffen Prohaska (2):
tiny fix in documentation of git-clone
git-config: test for 'do not forget "a.b.var" ends "a.var" section'.
* The 'master' branch has these since v1.5.2-rc3, in addition to the above.
Frank Lichtenheld (1):
cvsserver: Limit config parser to needed options
Jakub Narebski (2):
gitweb: Test if $from_id and $to_id are defined before comparison
gitweb: Check if requested object exists
Jan Hudec (1):
Minor fixup to documentation of hooks in git-receive-pack.
Jeff King (1):
git-add: allow path limiting with -u
Junio C Hamano (5):
Minor copyediting on Release Notes for 1.5.2
Add has_symlink_leading_path() function.
apply: do not get confused by symlinks in the middle
read-tree -m -u: avoid getting confused by intermediate symlinks.
Link to HTML version of external doc if available
Junio Hamano (1):
t9400: Use the repository config and nothing else.
Lars Hjemli (1):
git-archive: don't die when repository uses subprojects
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-05-13 22:30 Junio C Hamano
@ 2007-05-17 0:21 ` Junio C Hamano
2007-05-19 5:24 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-17 0:21 UTC (permalink / raw)
To: git
It probably would be more interesting to look at the earlier
"What's not in 1.5.2" messages, but here is the current status
of my tree on the 'stable' front.
I'd expect to have 1.5.1.5 from 'maint' perhaps on Saturday, and
1.5.2 from 'master' hopefully on Sunday if everything goes well.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Andy Whitcroft (1):
git name-rev writes beyond the end of malloc() with large generations
Frank Lichtenheld (3):
builtin-log.c: Fix typo in comment
Documentation: format-patch has no --mbox option
git-am: Clean up the asciidoc documentation
Jakub Narebski (1):
gitweb: Add a few comments about %feature hash
Jeff King (1):
format-patch: add MIME-Version header when we add content-type.
Johannes Schindelin (1):
import-tars: Use the "Link indicator" to identify directories
Junio C Hamano (2):
Fix git-clone buglet for remote case.
Prepare for 1.5.1.5 Release Notes
Quy Tonthat (1):
Documentation/branch: fix small typo in -D example
Steffen Prohaska (1):
Fixed link in user-manual
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (1):
Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
Frank Lichtenheld (1):
cvsserver: Don't send mixed messages to clients
Jakub Narebski (5):
gitweb: Fix "Use of unitialized value" warnings in empty repository
Documentation: Split description of pretty formats of commit log
gitweb: Do not use absolute font sizes
gitweb: Separate search regexp from search text
gitweb: Empty patch for merge means trivial merge, not no differences
Jeff King (1):
Documentation/git-add: clarify -u with path limiting
Johan Herland (2):
Fix signedness on return value from xread()
Ensure return value from xread() is always stored into an ssize_t
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-05-17 0:21 ` Junio C Hamano
@ 2007-05-19 5:24 ` Junio C Hamano
2007-05-23 21:46 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-19 5:24 UTC (permalink / raw)
To: git
I've done release 1.5.1.5, which hopefully would be the second
from the last release in 1.5.1 maintenance series (I somehow
ended up missing documentation formatting updates from Matthias
Kestenholz, which fix longstanding ugly formatting mistakes in
some manual pages).
The tip of 'master' will be tagged v1.5.2 hopefully in 24 hours.
Nothing earth shattering since the last message of this series.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
J. Bruce Fields (10):
user-manual: revise birdseye-view chapter
glossary: expand and clarify some definitions, prune cross-references
user-manual: move quick-start to an appendix
Documentation: remove howto's now incorporated into manual
user-manual: move howto/make-dist.txt into user manual
user-manual: move howto/using-topic-branches into manual
user-manual: add a "counting commits" example
user-manual: introduce git
user-manual: listing commits reachable from some refs not others
user-manual: reorganize public git repo discussion
Johannes Schindelin (1):
Add a birdview-on-the-source-code section to the user manual
Junio C Hamano (1):
GIT v1.5.1.5
Matthias Kestenholz (2):
Documentation: Added [verse] to SYNOPSIS where necessary
Documentation: Reformatted SYNOPSIS for several commands
Michael Hendricks (2):
git-send-email: allow leading white space on mutt aliases
Document core.excludesfile for git-add
Petr Baudis (1):
Documentation: git-rev-list's "patterns"
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (1):
Fix crlf attribute handling to match documentation
Jakub Narebski (2):
gitweb: Fix error in git_patchset_body for deletion in merge commit
gitweb: Fix "Use of uninitialized value" warning in git_feed
Junio C Hamano (3):
gitweb: fix another use of undefined value
Add link to 1.5.1.5 release notes.
Documentation/git.txt: Update links to older documentation pages.
Petr Baudis (4):
gitweb: Normalize searchbar font size
gitweb: Add support for grep searches
gitweb: Allow arbitrary strings to be dug with pickaxe
gitweb: Remove redundant $searchtype setup
René Scharfe (1):
git-archive: convert archive entries like checkouts do
Shawn O. Pearce (1):
git-gui: Gracefully handle bad TCL_PATH at compile time
Steffen Prohaska (1):
Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-05-19 5:24 ` Junio C Hamano
@ 2007-05-23 21:46 ` Junio C Hamano
2007-05-29 10:12 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-23 21:46 UTC (permalink / raw)
To: git
Although there are a few post release fixups queued for v1.5.2.1
on 'maint' already, all things considered I must say v1.5.2 was
a quite good release. There isn't a huge "oops, hand me a brown
paper bag please" fix yet. Knock, knock...
On the 'master' front, as promised, the first batch that were on
hold since v1.5.2-rc1 is in. Nothing earth-shattering, really.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.2.
Fernando J. Pereda (1):
Use PATH_MAX instead of TEMPFILE_PATH_LEN
Frank Lichtenheld (2):
t1300: Add tests for git-config --bool --get
git-config: Correct asciidoc documentation for --int/--bool
Jim Meyering (1):
git-daemon: don't ignore pid-file write failure
Johannes Schindelin (2):
SubmittingPatches: mention older C compiler compatibility
git-status: respect core.excludesFile
Jonas Fonseca (1):
branch: fix segfault when resolving an invalid HEAD
Junio C Hamano (2):
annotate: make it work from subdirectories.
git-cvsserver: fix disabling service via per-method config
Paolo Bonzini (1):
Document branch.autosetupmerge.
Stephan Springl (1):
Use git-for-each-ref to check whether the origin branch exists.
Sven Verdoolaege (1):
unpack-trees.c: verify_uptodate: remove dead code
* The 'master' branch has these since v1.5.2, in addition to the above.
Alex Riesen (1):
Fix the progress code to output LF only when it is really needed
Dana How (1):
Custom compression levels for objects and packs
Jakub Narebski (2):
gitweb: Add test t9500 for gitweb (as standalone script)
Add an option to git-ls-tree to display also the size of blob
James Bowes (1):
Add colour support in rebase and merge tree diff stats output.
Junio C Hamano (2):
git-apply: Fix removal of new trailing blank lines.
Fix command line parameter parser of revert/cherry-pick
Marco Costalba (1):
Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
Martin Waitz (1):
rename dirlink to gitlink.
Michael S. Tsirkin (1):
connect: display connection progress
Nicolas Pitre (3):
allow for undeltified objects not to be reused
make "repack -f" imply "pack-objects --no-reuse-object"
deprecate the new loose object header format
Petr Baudis (1):
git-rev-list: Add regexp tuning options
Shawn O. Pearce (1):
Teach git-describe how to run name-rev
Sven Verdoolaege (1):
git-update-ref: add --no-deref option for overwriting/detaching ref
Theodore Ts'o (1):
Add --aggressive option to 'git gc'
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-05-23 21:46 ` Junio C Hamano
@ 2007-05-29 10:12 ` Junio C Hamano
2007-06-02 21:09 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-05-29 10:12 UTC (permalink / raw)
To: git
Time for 1.5.2.1 perhaps.
The second batch of random changes are in 'master' now. This is
a rather large-ish looking one. Handle it with care.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Andy Parkins (2):
Fix mishandling of $Id$ expanded in the repository copy in convert.c
Add test case for $Id$ expanded in the repository
Carlos Rica (1):
fix memory leak in parse_object when check_sha1_signature fails
Eric Wong (1):
git-svn: avoid md5 calculation entirely if SVN doesn't provide one
Frank Lichtenheld (3):
cvsserver: Correct inetd.conf example in asciidoc documentation
cvsserver: Note that CVS_SERVER can also be specified as method variable
cvsserver: Fix some typos in asciidoc documentation
Jakub Narebski (3):
Documentation: Clean up links in GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Add definition of "evil merge" to GIT Glossary
James Bowes (1):
Documentation: fix git-config.xml generation
James Y Knight (1):
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
Jeff King (2):
git-am: use printf instead of echo on user-supplied strings
More echo "$user_message" fixes.
Johan Herland (1):
Fix stupid typo in lookup_tag()
Jonas Fonseca (1):
Update bash completion to ignore some more plumbing commands
Junio C Hamano (3):
name-rev: tolerate clock skew in committer dates
git-commit: use printf '%s\n' instead of echo on user-supplied strings
Add tests for the last two fixes.
Nguyễn Thái Ngọc Duy (1):
Makefile: Remove git-fsck and git-verify-pack from PROGRAMS
Shawn O. Pearce (12):
git-gui: Tighten internal pattern match for lib/ directory
Refactor fast-import branch creation from existing commit
Fix possible coredump with fast-import --import-marks
Hide the plumbing diff-{files,index,tree} from bash completion
Teach bash completion about git-shortlog
Remove a duplicate --not option in bash completion
Update bash completion header documentation
Teach bash completion about 'git remote update'
Teach bash completion about recent log long options
Update bash completion for git-config options
Correct key bindings to Control-<foo>
git-gui: Guess our share/git-gui/lib path at runtime if possible
Simon Hausmann (2):
fast-import: Fix uninitialized variable
fast-import: Fix crash when referencing already existing objects
Steffen Prohaska (1):
user-manual: fixed typo in example
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (6):
Add run_command_v_opt_cd: chdir into a directory before exec
Add ability to specify environment extension to run_command
Allow environment variables to be unset in the processes started by run_command
Verbose connect messages to show the IP addresses used
Add another verbosity level to git-fetch
Add a configuration option to control diffstat after merge
Dana L. How (7):
Alter sha1close() 3rd argument to request flush only
git-repack --max-pack-size: new file statics and code restructuring
git-repack --max-pack-size: write_{object,one}() respect pack limit
git-repack --max-pack-size: split packs as asked by write_{object,one}()
git-repack --max-pack-size: add option parsing to enable feature
pack-objects: clarification & option checks for --max-pack-size
Ensure git-repack -a -d --max-pack-size=N deletes correct packs
Daniel Barkalow (5):
Move remote parsing into a library file out of builtin-push.
Move refspec parser from connect.c and cache.h to remote.{c,h}
Add handlers for fetch-side configuration of remotes.
Update local tracking refs when pushing
Move refspec pattern matching to match_refs().
Fernando J. Pereda (1):
Teach mailsplit about Maildir's
Frank Lichtenheld (5):
t9400: Add test cases for config file handling
t9400: Add some more cvs update tests
t9400: Add some basic pserver tests
t9400: Work around CVS' deficiencies
cvsserver: Handle 'cvs login'
Junio C Hamano (4):
pack-objects: pass fullname down to add_object_entry()
Teach "delta" attribute to pack-objects.
builtin-pack-objects: remove unnecessary code for no-delta
mailsplit: fix for more than one input files
Linus Torvalds (2):
Make "git gc" pack all refs by default
Make the pack-refs interfaces usable from outside
Mark Levedahl (1):
gitweb.perl - Optionally send archives as .zip files
Nicolas Pitre (3):
fixes to output of git-verify-pack -v
improve delta long block matching with big files
update diff-delta.c copyright
Robin Rosenberg (1):
Add option to cvs update before export
Shawn O. Pearce (1):
Allow contrib new-workdir to link into bare repositories
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-05-29 10:12 ` Junio C Hamano
@ 2007-06-02 21:09 ` Junio C Hamano
2007-06-07 2:08 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-02 21:09 UTC (permalink / raw)
To: git
I will do a v1.5.2.1 with 'maint' and push it out this weekend.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Frank Lichtenheld (2):
git-config: Various small fixes to asciidoc documentation
git-config: Improve documentation of git-config file handling
Jeff King (1):
Documentation: robustify asciidoc GIT_VERSION replacement
Jerald Fitzjerald (1):
decode_85(): fix missing return.
Josh Triplett (1):
Create a new manpage for the gitignore format, and reference it elsewhere
Kristian Høgsberg (1):
Use =20 when rfc2047 encoding spaces.
Linus Torvalds (1):
fix signed range problems with hex conversions
* The 'master' branch has these since the last announcement
in addition to the above.
James Bowes (1):
rev-parse: Identify short sha1 sums correctly.
Jonas Fonseca (2):
Fix git-am(1) synopsis formatting
git-rebase: suggest to use git-add instead of git-update-index
Julian Phillips (1):
Makefile: Use generic rule to build test programs
Junio C Hamano (1):
Add DLH to .mailmap
Martin Koegler (4):
builtin-pack-objects: don't fail, if delta is not possible
git-pack-objects: cache small deltas between big objects
builtin-pack-object: cache small deltas
diff-delta: use realloc instead of xrealloc
Nicolas Pitre (2):
fix repack with --max-pack-size
always start looking up objects in the last used pack first
Shawn O. Pearce (7):
Lazily open pack index files on demand
Micro-optimize prepare_alt_odb
Attempt to delay prepare_alt_odb during get_sha1
Test for recent rev-parse $abbrev_sha1 regression
Simplify index access condition in count-objects, pack-redundant
Ensure the pack index is opened before access
Style nit - don't put space after function names
Theodore Ts'o (1):
Fix minor grammatical typos in the git-gc man page
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-06-02 21:09 ` Junio C Hamano
@ 2007-06-07 2:08 ` Junio C Hamano
2007-06-13 20:11 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-07 2:08 UTC (permalink / raw)
To: git
It has been slow on the stable front.
* The 'maint' branch has these fixes since the last announcement.
Johannes Sixt (1):
Accept dates before 2000/01/01 when specified as seconds since the epoch
Michael Milligan (1):
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
Sam Vilain (1):
fix documentation of unpack-objects -n
* The 'master' branch has these since the last announcement
in addition to the above.
Geert Bosch (1):
Unify write_index_file functions
Johannes Schindelin (5):
Update to SubmittingPatches
git-fsck: learn about --verbose
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
t5000: skip ZIP tests if unzip was not found
Johannes Sixt (1):
Makefile: Remove git-merge-base from PROGRAMS.
Jon Loeliger (1):
Add the --numbered-files option to git-format-patch.
Josh Triplett (1):
Fix typo in git-mergetool
Junio C Hamano (4):
Remove git-applypatch
Release Notes: start preparing for 1.5.3
git-apply: what is detected and fixed is not just trailing spaces.
git-branch --track: fix tracking branch computation.
Lars Hjemli (2):
Add git-submodule command
Add basic test-script for git-submodule
Martin Koegler (1):
gitweb: Handle non UTF-8 text better
Matthias Lederhofer (2):
add git-filter-branch to .gitignore
make clean should remove all the test programs too
Matthijs Melchior (1):
Teach git-tag about showing tag annotations.
Petr Baudis (1):
git-applymbox: Remove command
Pierre Habouzit (1):
$EMAIL is a last resort fallback, as it's system-wide.
Randal L. Schwartz (1):
Add test-sha1 to .gitignore.
Sam Vilain (1):
Don't assume tree entries that are not dirs are blobs
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-06-07 2:08 ` Junio C Hamano
@ 2007-06-13 20:11 ` Junio C Hamano
2007-06-13 22:31 ` Johannes Schindelin
2007-06-21 7:21 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-06-13 20:11 UTC (permalink / raw)
To: git
I'll be dormant for the next 72 hours or so, so please do not
get alarmed if no patches sent to the list is applied to my
tree. Please remind me about them after they are commented on,
revised and improved, and final revision got agreed to be good
on the list.
WIth a big usability change to git-gui blame viewer on 'maint',
I think it is time to do 1.5.2.2 this weekend (if I have the
energy, that is).
The 'master' side has quite a lot of clean-ups and improvements
in the fringes, but nothing big has come out of 'next' since
1.5.2. I would want to start the 1.5.3-rc cycle, after merging
at least the submodule Porcelain (Lars) and filter-tree
(Johannes and Pasky). There are other topics already on 'next'
that are probably 1.5.3 material as well.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (2):
Make the installation target of git-gui a little less chatty
Fix clone to setup the origin if its name ends with .git
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Junio C Hamano (1):
checkout: do not get confused with ambiguous tag/branch names
Kristian Høgsberg (1):
Unquote From line from patch before comparing with given from address.
Luiz Fernando N. Capitulino (1):
git-cherry: Document 'limit' command-line option
Matthijs Melchior (1):
New selection indication and softer colors
Sam Vilain (1):
Don't assume tree entries that are not dirs are blobs
Shawn O. Pearce (47):
git-gui: Allow creating a branch when none exists
git-gui: Allow as few as 0 lines of diff context
git-gui: Don't quit when we destroy a child widget
git-gui: Attach font_ui to all spinbox widgets
git-gui: Verify Tcl/Tk is new enough for our needs
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Add a 4 digit commit abbreviation to the blame viewer
git-gui: Cleanup blame::new widget initialization
git-gui: Remove empty blank line at end of blame
git-gui: Improve the coloring in blame viewer
git-gui: Simplify consecutive lines that come from the same commit
git-gui: Use arror cursor in blame viewer file data
git-gui: Display tooltips in blame viewer
git-gui: Highlight the blame commit header from everything else
git-gui: Remove unnecessary reshow of blamed commit
git-gui: Cleanup minor style nit
git-gui: Space the commit group continuation out in blame view
git-gui: Show author initials in blame groups
git-gui: Allow the user to control the blame/commit split point
git-gui: Display a progress bar during blame annotation gathering
git-gui: Allow digging through history in blame viewer
git-gui: Combine blame groups only if commit and filename match
git-gui: Show original filename in blame tooltip
git-gui: Use a label instead of a button for the back button
git-gui: Clip the commit summaries in the blame history menu
git-gui: Remove the loaded column from the blame viewer
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Use lighter colors in blame view
git-gui: Make the line number column slightly wider in blame
git-gui: Automatically expand the line number column as needed
git-gui: Remove unused commit_list from blame viewer
git-gui: Better document our blame variables
git-gui: Cleanup redundant column management in blame viewer
git-gui: Switch internal blame structure to Tcl lists
git-gui: Label the uncommitted blame history entry
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Display the "Loading annotation..." message in italic
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display both commits in our tooltips
git-gui: Jump to original line in blame viewer
git-gui: Use three colors for the blame viewer background
git-gui: Improve our labeling of blame annotation types
git-gui: Favor the original annotations over the recent ones
git-gui: Changed blame header bar background to match main window
git-gui: Include 'war on whitespace' fixes from git.git
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Save geometry before the window layout is damaged
william pursell (1):
Make command description imperative statement, not third-person present.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix push with refspecs containing wildcards
Alexandre Julliard (1):
pack-check: Sort entries by pack offset before unpacking them.
Andy Whitcroft (3):
cvsimport: add support for new style remote layout
cvsimport: update documentation to include separate remotes option
cvsimport: add <remote>/HEAD reference in separate remotes more
Aneesh Kumar K.V (2):
gitview: Fix the blame interface.
gitview: run blame with -C -C
Dan McGee (1):
git-mergetool: Allow gvimdiff to be used as a mergetool
Elvis Pranskevichus (1):
Use git-tag in git-cvsimport
Eric Wong (3):
git-svn: cleanup: factor out longest_common_path() function
git-svn: test for creating new directories over svn://
git-svn: reduce stat() calls for a backwards compatibility check
Frank Lichtenheld (1):
cvsserver: Make req_Root more critical of its input data
Jakub Narebski (6):
gitweb: Provide links to commitdiff to each parent in 'commitdiff' view
gitweb: Improve "next" link in commitdiff view
gitweb: Split git_patchset_body into separate subroutines
gitweb: Create special from-file/to-file header for combined diff
gitweb: Add links to blobdiffs in from-file/to-file header for merges
gitweb: '--cc' for merges in 'commitdiff' view
Jeff King (2):
cmd_log_init: remove parsing of --encoding command line parameter
refactor dir_add_name
Jim Meyering (1):
Don't dereference a strdup-returned NULL
Johan Herland (1):
Remove unnecessary code and comments on non-existing 8kB tag object restriction
Johannes Schindelin (2):
git-merge-file: refuse to merge binary files
Teach diff to imply --find-copies-harder upon -C -C
Johannes Sixt (3):
Avoid double-slash in path names that depend on $(sharedir).
Remove trailing slash from $(template_dir).
git-remote show: Also shorten non-fast-forward refs in the 'push' listing
Junio C Hamano (12):
War on whitespace
Test wildcard push/fetch
More missing static
More missing static
Even more missing static
git-blame: do not indent with spaces.
git-blame -w: ignore whitespace
mktag: minimally update the description.
Makefile: common-cmds.h depends on generate-cmdlist.sh script
Makefile: allow generating git.o for debugging purposes
-Wold-style-definition fix
More static
Lars Hjemli (2):
git-submodule: move cloning into a separate function
git-submodule: clone during update, not during init
Linus Torvalds (1):
Makefile: add an explicit rule for building assembly output
Matthias Lederhofer (1):
gitweb: change filename/directory name of snapshots
Michael Ellerman (2):
gitview: Use new-style classes
gitview: Define __slots__ for Commit
Pierre Habouzit (2):
Active_nr is unsigned, hence can't be < 0
Missing statics.
René Scharfe (1):
t5000: silence unzip availability check
Shawn O. Pearce (10):
git gui 0.8.0
git-gui: GUI support for running 'git remote prune <name>'
git-gui: Show the git-gui library path in 'About git-gui'
git-gui: Enable verbose Tcl loading earlier
git-gui: Provide fatal error if library is unavailable
git-gui: Disable tearoff menus on Windows, Mac OS X
git-gui: Allow users to rename branches through 'branch -m'
git-gui: Allow users to delete remote branches
git-gui: Expose the merge.diffstat configuration option
git-gui: Internalize symbolic-ref HEAD reading logic
Theodore Ts'o (1):
git-mergetool: Make default selection of merge-tool more intelligent
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-06-13 20:11 ` Junio C Hamano
@ 2007-06-13 22:31 ` Johannes Schindelin
2007-06-14 7:12 ` Johannes Sixt
2007-06-21 7:21 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-06-13 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Wed, 13 Jun 2007, Junio C Hamano wrote:
> I would want to start the 1.5.3-rc cycle, after merging
> at least the submodule Porcelain (Lars) and filter-tree
> (Johannes and Pasky).
Isn't that Johannesses (and filter-branch)? :-)
FWIW I think that there lies a long road in front of us with
filter-branch, after submodule is merged in. I have no preference on what
should go in first, but filter-branch If My Plan Succeeds (TM) will help
transition from huge imports to subprojects.
So, even if I am not _that_ interested in subprojects myself, I _do_ want
to enhance filter-branch. IMHO filter-branch is yet another proof that
cogito -- even if it is now set to die -- was well worth it. Thanks Pasky.
Next plans are: make filter-branch a misnomer: actually be able to rewrite
more than one branch in one go, writing the outcome to the refs/rewritten/
namespace. IIRC that was Hannes' project, but I'll gladly step in there if
need be.
After that, I imagine automatic subprojects disentangling (maybe somewhat
related to Alex' suggestion), so you can say "this big project is actually
a subproject: directories a/, b/ and c/ are self-contained subprojects).
Of course, the nearest future from my POV is to actually implement the
missing tests :-)
Ciao,
Dscho
P.S.: Junio, wherever you are right now, have a nice time. Hopefully not
too stressful.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-06-13 20:11 ` Junio C Hamano
2007-06-13 22:31 ` Johannes Schindelin
@ 2007-06-21 7:21 ` Junio C Hamano
2007-06-25 9:43 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-21 7:21 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Add a local implementation of hstrerror for the system which do not have it
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Junio C Hamano (5):
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Do not use h_errno after connect(2): the function does not set it
cvsserver: Actually implement --export-all
Daniel Barkalow (1):
Fix pushing to a pattern with no dst
Frank Lichtenheld (3):
cvsserver: Add some useful commandline options
cvsserver: Let --base-path and pserver get along just fine
cvsserver: Actually implement --export-all
Gerrit Pape (1):
git-branch: cleanup config file when deleting branches
Ismail Dönmez (1):
Change default man page path to /usr/share/man
Jakub Narebski (8):
Document git rev-list --full-history
Document git read-tree --trivial
Document git rev-parse --is-inside-git-dir
Document git reflog --stale-fix
Document git rev-list --timestamp
Use tabs for indenting definition list for options in git-log.txt
Document git log --abbrev-commit, as a kind of pretty option
Document git log --full-diff
Junio C Hamano (8):
remote.c: refactor match_explicit_refs()
remote.c: refactor creation of new dst ref
remote.c: minor clean-up of match_explicit()
remote.c: fix "git push" weak match disambiguation
remote.c: "git-push frotz" should update what matches at the source.
git-push: Update description of refspecs and add examples
Documentation: update "stale" links for 1.5.2.2
INSTALL: explain how to build documentation
Lars Hjemli (6):
t7400: barf if git-submodule removes or replaces a file
git-submodule: remember to checkout after clone
Rename sections from "module" to "submodule" in .gitmodules
git-submodule: give submodules proper names
Add gitmodules(5)
gitmodules(5): remove leading period from synopsis
Sam Vilain (1):
git-svn: avoid string eval for defining functions
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-06-21 7:21 ` Junio C Hamano
@ 2007-06-25 9:43 ` Junio C Hamano
2007-07-02 0:16 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-06-25 9:43 UTC (permalink / raw)
To: git
Among many small fixes and some code churns, there are a few
notable topics from 'next'.
- git-filter-branch to rewrite history;
- git-add "Huh?" factor fix when attempting to add an empty directory;
- git-log and friends do not have the 16kB size limit for
commit log messages anymore;
- git-log and friends' --pretty=oneline treats the first
paragraph of a commit log message as the title line;
- "git-log --follow -- single-file";
Simon Hausmann and Shawn Pearce have shepherded a fast-import
based Perforce importer into contrib/fast-import area.
* The 'master' branch has these since the last announcement
Dave O'Neill (1):
Generate tags with correct timestamp (git-svnimport)
Gerrit Pape (1):
git-svn: trailing slash in prefix is mandatory with --branches/-b
Jeff King (4):
dir_struct: add collect_ignored option
builtin-add: simplify (and increase accuracy of) exclude handling
Fix ALLOC_GROW off-by-one
Fix ALLOC_GROW calls with obsolete semantics
Johannes Schindelin (7):
Add git-filter-branch
filter-branch: use $(($i+1)) instead of $((i+1))
filter-branch: fix behaviour of '-k'
Teach filter-branch about subdirectory filtering
pp_header(): work around possible memory corruption
diffcore-rename: favour identical basenames
filter-branch: add example to move everything into a subdirectory
Johannes Sixt (4):
filter-branch: Use rev-list arguments to specify revision ranges.
filter-branch: also don't fail in map() if a commit cannot be
mapped
filter-branch: Simplify parent computation.
filter-branch: subdirectory filter needs --full-history
Julian Phillips (1):
new-workdir: handle rev-parse --git-dir not always giving full path
Junio C Hamano (5):
t7003: make test repeatable
Lift 16kB limit of log message output
Extend --pretty=oneline to cover the first paragraph,
Two trivial -Wcast-qual fixes
git-send-email: Do not make @-less message ID
Linus Torvalds (2):
Finally implement "git log --follow"
Fix up "git log --follow" a bit..
Matthias Lederhofer (3):
filter-branch: prevent filters from reading from stdin
chmod +x git-filter-branch.sh
make dist: include configure script in tarball
Nanako Shiraishi (1):
Cloning from a repo without "current branch"
Shawn O. Pearce (2):
Avoid src:dst syntax as default bash completion for git push
Document git-gui, git-citool as mainporcelain manual pages
Sven Verdoolaege (1):
t9500: skip gitweb tests if perl version is too old
-- p4 --
Benjamin Sergeant (1):
git-p4 fails when cloning a p4 depo.
Han-Wen Nienhuys (28):
Cleanups
reformatting: break long lines.
rename apply() to applyCommit(); apply is a python builtin
add .dotest to .gitignore
Robustness fixes for pipes
cleanup
minor cleanups
clone and sync --keep-path to keep perforce path to module.
use string.strip() iso. slicing.
use strip() iso. slicing for removing \n
add --verbose to all commands.
Extract multiple paths concurrently.
Diverse cleanups
remove global .gitdir
Read p4 files in one batch.
Thinko, fix buglet.
store p4 user cache in home directory.
thinko.
read files before creating the commit.
don't p4 print deleted files.
only run p4 print if necessary
use p4CmdList() to get file contents in Python dicts. This is more
robust.
Cleanups & import into p4/master for local import
remove debug print
thinko: really ignore deleted files.
look for 'text' and 'binary' files.
print error message when p4 print fails (eg. due to permission
problems)
also strip p4/ from local imports.
Kevin Green (1):
git-p4: check for existence of repo dir before trying to create
Marius Storm-Olsen (7):
Make the command call silent
Replace \r\n with \n when importing from p4 on Windows
Ensure that the commit message is Windows formated (CRLF) before
invoking the editor.
Fix git-p4 clone (defaultDestination)
Fix single branch import into remotes
Exclude the HEAD symbolic ref from the list of known branches
Only use double quotes on Windows
Simon Hausmann (222):
Initial import of a python script to import changesets from
Perforce into git.
Added basic support for specifying the depot path to import from as
well as the range of perforce changes.
Slightly improved help usage output and made specifying the
trailing slash for the depot path optional.
Implemented basic support for converting the date of the perforce
change to the git format. The timezone isn't correctly set up
yet though.
Some fixes to the timezone conversion between the date of a
perforce change and the git commit.
Speed up the import of individual files from Perforce into git by
passing the output of "p4 print" directly to git fast-import.
Also try to set the mode of the file in git correctly based on
file type heuristics.
Removed unused p4cat function and added helper function for the
perforce python interface (p4Cmd).
Changed the import mechanism to write to git fast-import through a
pipe instead of having p4-fast-export write to stdout and let
the caller connect it to git fast-import.
Minor code cleanups and ported some p4 interfacing code over to the
p4 python mode.
Instead of parsing the output of "p4 users" use the python objects
of "p4 -G users".
Ported the remaining functions that parsed p4 shell output over to
the p4 python interface.
Avoid calling fstat for every imported file (slow!) and instead
read the file data first into the python process and use the
length of the bytes read for the size field of git fast-import.
Permit calling p4-fast-export with a depot path that has the
typical ... wildcard at the end.
Fixed displaying import progress by calling flush on stdout.
Create a git tag for every changeset imported from perforce.
Fix file permissions of p4-fast-export.py to be executable.
Started working on incremental imports from Perforce.
Simplify the incremental import by elimination the need for a
temporary import branch.
Code cleanups, move the code to create a commit with fast-import
into a separate function out of the main loop.
Initial support for importing a directory from Perforce at a
specified revision.
Minor cleanups and print an error message of git fast-import if it
fails.
Fixed incremental imports by using the correct "from" command
instead of "merge" with git fast-import.
Make incremental imports easier to use by storing the p4 depot path
after an import in .git/config and re-using it when we're
invoked again later.
Make specifying the revision ranges more convenient.
Fix calculation of the newest imported revision for #head imports.
Catch io exceptions from git fast-import again and print the error
message.
Made the name of the git branch used for the perforce import
configurable through a new --branch=<name> commandline option.
Added a little helper script to debug the output of the p4 python
interface.
Minor code cleanups.
Avoid the excessive use of git tags for every perforce change and
instead just create one git tag for the last imported change.
Changed the default git import branch from "p4" to "master".
Added a little helper script to remove unused tags from the
perforce import.
Create lightweight git tags (using the "reset" trick) for the
incremental import instead of full-blown ones. Also fix parsing
the output of git name-rev for figuring out the last imported
p4 change number.
Cleanups, remove unused variable.
Code cleanups.
Started work on p4 branch detection (experimental!).
More fixes in heuristic p4 branch detection based on common path
components.
After marking a p4 branch as merged don't ever merge it in git
again.
Set git fast-import marks for every imported change for future use.
When trying to map p4 integrations to git merges just record it as
a single merge with the newest p4 change as secondary parent.
Make it possible to specify the p4 changes to import through a text
file (for debugging) and made various improvements to the
branch/merge heuristic detection.
Use sets.Set() instead of set() to run also with older versions of
Python.
Fix single-branch imports by skipping the branch/merge detection
correctly.
Added p4 delete behavioural emulation as todo item.
Added support for --silent so that p4-fast-export can be called
from cronjobs.
More work in --silent support.
Don't print a plain newline at the end of the execution (avoids
bogus cron error mails).
Adjust the output parsing of git name-rev to handle the output of
the latest git version.
Work in progress on detecting branches.
Changed --known-branches to take a file as argument instead of a
comma separated list.
Fixed p4-debug file extension.
Make the p4 data/command cache configurable through the
--cache-debug commandline option.
Minor code cleanups.
More code cleanups and preparations for more branch detection
heuristics.
More work on branch detection by implementing
changeIsBranchMerge().
Reduce the number of false "merges" by skipping "branch from"
entries in the integrated output as well as by ignoring
integrations of future (newer) changes.
Split up the cache commandline options into (command) cache and
data cache.
First version of a new script to submit changes back to perforce
from git repositories.
Fix git-dir option and allow reading log substitutions from a file
Lots of bugfixes to p4-git-sync.
Automatically operate on a temporary branch, needed for cherry-pick
to work when applying changes to
Be nice and use /usr/bin/env python for the git-p4 scripts
Ignore Apple resource files when importing from perforce to git.
Auto-detect the current git branch before submitting back to
perforce.
Use p4 revert ... instead of revert -a ... after submitting, to
make sure the p4 checkout is clean.
Default to interactive syncing
Improved the git dir detection.
Pass the right number of arguments to commit, fixes single-branch
imports.
Start moving the git-p4 tools into one single script.
Provide a little bit of help description for the git-p4 "tools".
First (untested) attempt at migrating p4-git-sync into the final
git-p4 script
Part of the code is copyright by Trolltech ASA.
sync-to-perforce is now called submit and fixed the gitdir check a
little bit
Completely untested "merge" of p4-fast-export.py into git-p4.py
Added missing "self"s to make the script evaluate correctly.
Fixed the initial version import by getting the file index correct
by correctly skipping deleted files.
Removed p4-fast-export and p4-git-sync as they've been integrated
into git-p4 now.
Start of the git-p4 documentation.
Documentation enhancements.
Added experimental but super-fast --apply-as-patch option to git-p4
submit
Fix support for deletions in git-p4 submit when using
--apply-as-patch by filtering out deletions in the diff-tree
output.
Made --apply-as-patch the default for git-p4 submit as it's
significantly faster.
Make it possible to invoke git-p4 from within subdirectories of a
git working tree.
Don't show the submit template and the diff first in less but show
it in $editor right away
Removed the .py extension from git-p4 as it's annoying to type
every time.
Changed the format of the imported log message slightly, so that
it's easier to parse again.
Changed the default branch for imports from "master" to "p4"
Added some helper function(s) to parse the depot path and change
number from the log message
Helper function to check the existance of a revision
Set the default branch in run, not in the constructor
Brand new smart incremental import that doesn't need tags or git
repo-config :)
Make it possible to run git-p4 submit from within the git
repository
Use the new incremental import style by default
Different versions of p4 have different output for the where
command ;(
Minor cosmetic fixlet for the git-p4 submit sync question.
Prefer git command over git-command.
Don't try to parse any options with git-p4 debug but pass it
straight on to p4
git-p4 debug doesn't need a git repository
Added support for mapping p4 labels to git tags
Fix variable usage in tag import
Fix the docs for git-p4 submit and turn git-p4 submit --master=foo
into
Fix "compilation" :)
Clean up python class names.
Added git-p4 rebase convenience
Provide a tree summary after git-p4 rebase
Turn off potentially slow label detection by default
Honor --silent for labels
Added git-p4 clone convenience command
Fix file determination for #head imports
fix variable usage (oops)
Added a simple example of usage to the "documentation" :)
Allow for convenient rebasing after git-p4 submit
Print an error message of some sort if git fast-import fails.
Fix the timezone formatting. Now qgit also displays (parses) it
correctly.
Removed the old patch apply code from git-p4 submit.
Slightly improved formatting of the raw_input questions.
A new attempt at fixing the child-fast-import-process-not-finished
race condition
Handle patch errors in git-p4 submit better.
Doc cleanups.
Micro cleanup
cleanup, renamed self.globalPrefix to self.depotPath
Cleanup, removed the old tagging code
Document some implementation details, for the curious... :)
Use the subprocess module instead of popen2 to make it work on
Windows.
Added a little .bat wrapper from Marius
Make sure all popen calls use binary mode (for Windows) and
Make submitting work on Windows.
Converted to unix newlines
Fix git-p4 clone //depot/project (head import)
Make git-p4 work with bare repositories.
Added the possibility of skipping patches during git-p4 submit
Give a better hint if git-p4 submit fails
Fix calling git-p4 rebase from within a subdirectory (git rebase
wants to be in toplevel)
A little todo note before I forget it :), based on a suggestion
from Lars.
Fixing syncing (gitdir discovery / cd) for bare repositories
Always pass a sha1 for the initial parent so that git-fast-import
doesn't think
Clean up code duplication for revision parsing and fix previous
commit to not
Removed cleantags command. It doesn't have any meaning anymore.
Removed ancient and unused code to find the last imported revision
from previous imports
Create the origin based import branch using git update-ref instead
of git branch
Changed the default p4 import branch to be
refs/remotes/p4/{HEAD,master}
Bite the bullet and automatically convert old style refs/heads/p4
repositories
Added support for git-p4 sync/rebase --with-origin. See git-p4.txt
for details :)
Removed todo item that is implemented :)
Fix branch setup after initial clone.
Removed unused cache variables.
Started rewriting the branch detection, based on "p4 branches" and
"p4 branch -o foo".
Give branches a nice project prefix and don't bail out on clone if
we failed
More work on the incremental importing of multiple branches.
Cleanup/speed up the branch<> file split and removed change range
limitation that I added
More cleanups and speedups for labels and branches
Removed unused variable, more cleanups
Cache the output of "p4 users" for faster syncs on high latency
links.
Fix gitdir not being set when cloning. Needed for writing the p4
users cache.
Oops, not only /set/ gitdir on clone, also set it /correctly/ :)
Use git format-patch and git apply --apply when extracting patches
from git and
Added support for git-p4 submit --direct (experimental)
Specifying --detect-branches is now only needed for the initial
clone/sync.
Had an idea for debugging, record it :)
Another (potentially life-saving) idea for submit --direct
Improved output for multi branch imports and noted another little
todo item
Fix conversion from old style heads/p4 to remotes/p4/master
Fix error detection with git-p4 submit when the requested depot
path is not in the client view.
Fix git symbolic-ref warning on initial clone
Detect with git-p4 submit --direct when there are no changes in the
working directory
Make git-p4 submit --direct safer by also creating a git commit
Added a rollback command for debugging. It sets back the heads of
the p4 branches to the specified p4 change number or earlier.
Fix branch detection in multi-branch imports
Fixes for rollback, delete branches that did not exist at the
specified p4 change
Added support for importing multiple branches into refs/heads
instead of just refs/remotes
Added support for --max-changes=<count> to ease import debugging
Use refs/heads/* instead of refs/heads/p4/* for local imports
Doc updates
Avoid calling git symbolic-ref refs/heads/p4//HEAD (double slash)
Make rollback work with locally imported branches
Don't make len(p4Cmd("p4 changes -m 1 //foo/...")) == 0 succeed
when the p4 command itself failed.
Oops, fill the /list/ correct with the p4 exit code.
Catch p4 errors in rollback early enough (before deleting refs!)
Fix p4 execution in git-p4 rollback.
Fix multi-branch import with --silent.
Load the user map from p4 only once at run-time.
Fix creating the remotes/p4 branches based on origin/* for the
multi-branch import
Forgot to remove this return statement from debugging
Added support for --with-origin with multi-branch imports
Oops, fix --with-origin to /really/ also call git fetch :)
Avoid creating non-p4 branches in remotes/p4 off of remotes/origin
Make git-p4 work with packed refs (don't use os.path.exists to
check for the
Make --with-origin also work without origin :)
Make --with-origin the default for syncing.
Shortcut the case where we have no origin branch
Forgot to remove this TODO item when I made --with-origin the
default :)
Added git-p4 submit --trust-me-like-a-fool for the adventurous
users :)
Fix creation of refs/remotes/p4/HEAD symbolic ref
Fix my email address, this isn't really KDE related :)
In *_pipe print the command that failed if it fails.
Fix typo in listExistingP4Branches that broke sync.
Fix support for "depot-path" in older git-p4 imports
Fix common path "calculation" from logs of multiple branches.
Don't attempt to set the initialParent on multi-branch imports
(useless).
Hack to make the multi-branch import work again with
self.depotPaths now that
Fix git-p4 rebase
Fix git-p4 submit
Fix depot-path determination for git-p4 submit
Make clone behave like git clone by default again.
Make git-p4 submit detect the correct reference (origin) branch
when
Only get the expensive branch mapping from the p4 server when not
Fixed the check to make sure to exclude the HEAD symbolic refs when
updating
Fix updating/creating remotes/p4/* heads from origin/p4/*
Fix project name guessing
Fix depot-paths encoding for multi-path imports (don't split up
//depot/path/foo)
Fix support for explicit disabling of syncing with the origin
Write out the options tag in the log message of imports only if we
actually have
Provide some information for single branch imports where the
commits go
Mention remotes/p4/master also in the documentation.
git-p4 submit: Fix missing quotes around p4 commands to make them
work with spaces in filenames
Moved the code from git-p4 submit to figure out the upstream branch
point
Fix git-p4 rebase to detect the correct upstream branch instead of
unconditionally
Fix initial multi-branch import.
Fix the branch mapping detection to be independent from the order
of the "p4 branches" output.
Warn about conflicting p4 branch mappings and use the first one
found.
Added git-p4 branches command that shows the mapping of perforce
depot paths to imported git branches.
Make it possible to specify the HEAD for the internal
findUpstreamBranchPoint function.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-06-25 9:43 ` Junio C Hamano
@ 2007-07-02 0:16 ` Junio C Hamano
2007-07-13 6:06 ` What's in git.git Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-07-02 0:16 UTC (permalink / raw)
To: git
Will do a 1.5.2.3 with the tip of 'maint' probably mid-week and
a 1.5.3-rc1 at about the same time from 'master', hopefully with
a few topics that have been in 'next', and also some "discussed
but forgotten" fixes on the list if somebody kindly can remind
me ;-).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Frank Lichtenheld (2):
config: Complete documentation of --get-regexp
config: Change output of --get-regexp for valueless keys
Linus Torvalds (1):
Fix zero-object version-2 packs
Matt Kraai (1):
Correct the name of NO_R_TO_GCC_LINKER in the comment describing
it.
Sam Vilain (3):
cleanup merge-base test script
repack: improve documentation on -a option
git-remote: document -n
Shawn O. Pearce (5):
git-gui: Correctly install to /usr/bin on Cygwin
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Don't require $DISPLAY just to get --version
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
Sven Verdoolaege (1):
Ignore submodule commits when fetching over dumb protocols
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Roben (2):
git-send-email: Add --threaded option
git-send-email: make options easier to configure.
Alex Riesen (1):
Avoid perl in t1300-repo-config
Alexandre Vassalotti (1):
git-tag: Fix "can't shift that many".
Brian Gernhardt (1):
Fix t5516-fetch for systems where `wc -l` outputs whitespace.
Carlos Rica (3):
Fix git-stripspace to process correctly long lines and spaces.
Add test script for git-stripspace.
Add test-script for git-tag
Frank Lichtenheld (2):
config: Add --null/-z option for null-delimted output
config: add support for --bool and --int while setting values
Gerrit Pape (1):
git-cvsimport: force checkout of working tree after initial import
Jim Meyering (3):
detect close failure on just-written file handles
Don't ignore a pack-refs write failure
git-log: detect dup and fdopen failure
Johannes Schindelin (2):
t7004: ship trustdb to avoid gpg warnings
git add: respect core.filemode with unmerged entries
Junio C Hamano (2):
Add core.quotepath configuration variable.
Update draft Release Notes for 1.5.3
Linus Torvalds (3):
Clean up internal command handling
Check for IO errors after running a command
git: Try a bit harder not to lose errno in stdio
Mark Levedahl (5):
gitk: Make selection highlight color configurable
gitk: Update fontsize in patch / tree list
gitk: Allow specifying tabstop as other than default 8 characters.
gitk: Use a spinbox for setting tabstop settings
gitk: Update selection background colorbar in prefs dialog
Matthias Lederhofer (10):
rev-parse: document --is-inside-git-dir
rev-parse: introduce --is-bare-repository
test git rev-parse
introduce GIT_WORK_TREE to specify the work tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
extend rev-parse test for --is-inside-work-tree
test GIT_WORK_TREE
setup_git_directory: fix segfault if repository is found in cwd
filter-branch: always export GIT_DIR if it is set
make git barf when an alias changes environment variables
Michael Krelin (1):
git-svn: honor ~/.subversion/ client cert file settings.
Paul Mackerras (18):
gitk: Use the -q flag to git checkout
gitk: New infrastructure for working out branches & previous/next
tags
gitk: Don't try to list large numbers of tags or heads in the
details pane
gitk: Add some more comments to the optimize_rows procedure
gitk: Improve the behaviour of the initial selection
gitk: Implement a simple scheduler for the compute-intensive stuff
gitk: Cope with commit messages with carriage-returns and initial
blank lines
gitk: Disable the head context menu entries for the checked-out
branch
gitk: Store ids in rowrangelist and idrowranges rather than row
numbers
gitk: New algorithm for drawing the graph lines
gitk: Show local uncommitted changes as a fake commit
gitk: Speed up the reading of references
gitk: Get rid of the childlist variable
gitk: Add a "reset branch to here" row context-menu operation
gitk: Limit how often we change the canvas scrolling region
gitk: Fix bug causing nearby tags/heads to sometimes not be
displayed
gitk: Improve handling of whitespace and special chars in filenames
gitk: Add a progress bar to show progress while resetting
Quy Tonthat (1):
git.spec: RPM failed, looking for wrong files.
René Scharfe (2):
diffcore-rename: don't change similarity index based on basename
equality
diff: round down similarity index
Sam Vilain (2):
git-svn: use git-log rather than rev-list | xargs cat-file
git-svn: cache max revision in rev_db databases
Shawn O. Pearce (3):
git-gui: Quiet our installation process
Teach bash how to complete +refspec on git-push
Correct usages of sed in git-tag for Mac OS X
Simon Hausmann (1):
git-new-workdir: Fix shell warning about operator == used with
test.
Theodore Ts'o (1):
Don't fflush(stdout) when it's not helpful
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git
2007-07-02 0:16 ` Junio C Hamano
@ 2007-07-13 6:06 ` Junio C Hamano
2007-07-28 8:47 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-07-13 6:06 UTC (permalink / raw)
To: git
Executive summary:
* (maint) hopefully the last maintenance release for v1.5.2
codebase, v1.5.2.4, is out.
* (master) v1.5.3 is nicely progressing and we have v1.5.3-rc1
out, but it has a serious last minute glitch in pack-objects,
so please do not use "git-gc", or "git-repack" from vanilla
v1.5.3-rc1.
v1.5.3-rc1-1-g7d7baa5 or later should be Ok.
* (next/pu) No topics are cooking in 'next' right now, although
I might apply a few series I did not pick up from the list in
the past few days, just to keep them from getting lost.
As usual, v1.5.3-rc1 means:
* I personally will be using 'master' version for my work until
v1.5.3 final (I usually run 'next', and switch to 'master'
after -rc0); I ask contributors to do the same to shake out
the last minute bugs from 'master'.
* No more features and large code churning on 'master' until
v1.5.3 final.
* Bugfixes and documenation updates are always welcomed, but
even more so than usual until v1.5.3 final.
I'll send out a draft release notes for v1.5.3 in a separate
message.
----------------------------------------------------------------
* The 'maint' branch spawned 1.5.2.4 with accumulated fixes.
Most notably, we are in sync with git-gui 0.7.5.
* The 'master' branch has these since the last announcement;
we are at v1.5.3-rc1 plus a few fixes.
Adam Roben (1):
format-patch: Add format.subjectprefix config option
Alecs King (1):
fix remote.origin.url in tutorial.txt
Alex Riesen (4):
Handle missing prefix for "Subject:" as if no prefix given
Handle format.subjectprefix for every command which accepts
--pretty
Fix t5516 to create test repo without hooks
Add -v|--verbose to git remote to show remote url
Andrew Ruder (2):
Remove USE_PAGER from git-pickaxe and git-annotate
Add urls.txt to git-clone man page
Brian Downing (10):
pack-objects: Prefer shallower deltas if the size is equal
gitk: Fix for tree view ending in nested directories
Pack information tool
Correct shebang line for contrib/stats/packinfo.pl
Don't try to delta if target is much smaller than source
Support fetching the memory usage of a delta index
Add functions for parsing integers with size suffixes
Add pack-objects window memory usage limit
Add --window-memory option to git-repack
Add documentation for --window-memory, pack.windowMemory
Brian Gernhardt (1):
Add core.pager config variable.
CJ van den Berg (1):
git-submodule: Fix two instances of the same typo
Carlos Rica (5):
t7004: Skip tests for signed tags in an old version of gpg.
t0030: Remove repeated instructions and add missing &&
t0030: Add tests with consecutive text lines and others with spaces
added.
t7004: Add tests for the git tag -n option.
Function stripspace now gets a buffer instead file descriptors.
Daniel Barkalow (2):
Add allocation and freeing functions for struct refs
Some cosmetic changes to remote library
David Kastrup (1):
Add missing functions to contrib/emacs/vc-git.el
Emil Medve (1):
git-submodule: Instead of using only annotated tags, use any tags.
Eric Wong (2):
git-svn: allow dcommit to retain local merge information
git-svn: fix blocking with svn:// servers after do_switch
Frank Lichtenheld (1):
cvsserver: always initialize state in argsplit()
Gerrit Pape (1):
git-commit: don't add multiple Signed-off-by: from the same
identity
Jakub Narebski (3):
Update git-merge documentation.
Document long options '--message=<msg>' and '--no-commit'
Document git commit --untracked-files and --verbose
James Bowes (1):
stash: allow running from a subdirectory
Jeff King (6):
git-stash: fix "no arguments" case in documentation
git-stash: fix "can't shift that many" with no arguments
git-stash: don't complain when listing in a repo with no stash
Documentation: quote {non-attributes} for asciidoc
Documentation: quote {non-attributes} for asciidoc
Documentation: minor cleanups to branch/checkout wording
Jeffrey C. Ollie (2):
Add an option to quiet git-init.
Quiet the output from git-init when cloning, if requested.
Johannes Schindelin (28):
Move the pick_author code to git-sh-setup
Teach rebase an interactive mode
rebase -i: several cleanups
rebase -i: provide reasonable reflog for the rebased branch
Teach rebase -i about --preserve-merges
Make '!' aliases more useful
git-fsck: add --lost-found option
Document git-filter-branch
Add diff-option --ext-diff
filter-branch: add a test for the commit removal example
filter-branch: make output nicer
filter-branch: a few more touch ups to the man page
filter-branch documentation: clarify which filters are eval'ed
filter-branch: fail gracefully when a filter fails
Future-proof source for changes in xdemitconf_t
Teach git-stash to "apply --index"
Enable "git rerere" by the config variable rerere.enabled
git-branch: default to --track
branch.autosetupmerge: allow boolean values, or "all"
rebase -i: handle --continue more like non-interactive rebase
rebase -i: actually show the diffstat when being verbose
rebase -i: remember the settings of -v, -s and -p when interrupted
rebase -i: put a nice warning into the todo list
rerere: record resolution even if file is not in merge base
Fix core.sharedRepository = 2
Fix --cherry-pick with given paths
Add for_each_remote() function, and extend remote_find_tracking()
branch --track: code cleanup and saner handling of local branches
Johannes Sixt (4):
Test 'git add' for unmerged entries when core.symlinks=false.
filter-branch: Avoid an error message in the map function.
filter-branch documentation: some more touch-ups.
Allow rebase to run if upstream is completely merged
Jonas Fonseca (1):
fsck --lost-found writes to subdirectories in .git/lost-found/
Junio C Hamano (30):
diffcore_count_changes: pass diffcore_filespec
diffcore_filespec: add is_binary
diffcore-delta.c: update the comment on the algorithm.
diffcore-delta.c: Ignore CR in CRLF for text files
git-stash: require "save" to be explicit and update documentation
Update public documentation links for 1.5.2.3
"git-push $URL" without refspecs pushes only matching branches
Rewrite "git-frotz" to "git frotz"
git-stash: make "save" the default action again.
Mark disused commit walkers officially deprecated.
Update draft Release Notes for 1.5.3
Update reflog message created for stashes
Do not check if getcwd() result begins with a slash.
Fix git-stash(1) markup.
git-stash: allow more descriptive reminder message when saving
Introduce diff_filespec_is_binary()
Per-path attribute based hunk header selection.
Fix configuration syntax to specify customized hunk header
patterns.
diff: honor binariness specified in attributes
gitweb: make repeated calls to git_get_project_owner() bearable
diff.c: make built-in hunk header pattern a separate table
git-gui: use "blame -w -C -C" for "where did it come from,
originally?"
git-stash: try reusing cached stat info as much as possible
Fix merge-one-file for our-side-added/our-side-removed cases
Document custom hunk header selection
revision.c: remove duplicated parents after history simplification
Revert 88494423 (removal of duplicate parents in the output
codepath)
Re-code builtin-branch.c in UTF-8
Update list of older git docs
GIT v1.5.3-rc1
Lars Hjemli (1):
git-submodule(1): update description and key names
Linus Torvalds (1):
Start deprecating "git-command" in favor of "git command"
Marcus Fritzsch (1):
Fixed a formulation mistake in Documentation/user-manual.txt
Matt Kraai (3):
Prefer EMAIL to username@hostname.
Change "added.moved or removed" to "added, moved or removed" in
Add [verse] to the SYNOPSIS section of git-submodule.txt.
Matt McCutchen (3):
gitweb: make search form generate pathinfo-style URLs
gitweb: make "No commits" in project list gray, not bold green
Makefile: rebuild git.o on version change, clean up git$X flags
Matthias Lederhofer (5):
ignore git-rebase--interactive
getenv/setenv: use constants if available
git-init: set core.worktree if GIT_WORK_TREE is specified
git-clone: split up long &&-command-chain and use a function for
cleanup
make git-clone GIT_WORK_TREE aware
Michael Hendricks (2):
git-send-email: allow an email alias for --from
gitweb: configurable width for the projects list Description column
Miklos Vajna (2):
gitweb: prefer git_get_project_owner() over get_file_owner()
gitweb: new cgi parameter: opt
Nanako Shiraishi (2):
Add git-stash script
Document git-stash
Nicolas Pitre (4):
apply delta depth bias to already deltified objects
script to display a distribution of longest common hash prefixes
reduce git-pack-objects memory usage a little more
Pack-objects: properly initialize the depth value
Paul Mackerras (6):
gitk: Fix the find and highlight functions
gitk: Fix bug in the anc_or_desc routine
gitk: Remove the unused stopfindproc function
gitk: Fix bug causing "can't read commitrow(0,n)" error
gitk: Use git log and add support for --left-right
gitk: Improve handling of -- and ambiguous arguments
René Scharfe (1):
diff-lib.c: don't strdup twice
Sean Estabrooks (1):
Alter git-checkout reflog message to include "from" branch
Shawn O. Pearce (36):
git-gui: Start blame windows as tall as possible
git-gui: Correct resizing of remote branch delete dialog
git-gui: Honor rerere.enabled configuration option
git-gui: New Git version check support routine
git-gui: Teach class system to support [$this cmd] syntax
git-gui: Abstract the revision picker into a mega widget
git-gui: Refactor the delete branch dialog to use class system
git-gui: Optimize for newstyle refs/remotes layout
git-gui: Maintain remote and source ref for tracking branches
git-gui: Allow users to match remote branch names locally
git-gui: Fast-forward existing branch in branch create dialog
git-gui: Enhance choose_rev to handle hundreds of branches
git-gui: Sort tags descending by tagger date
git-gui: Option to default new branches to match tracking branches
git-gui: Automatically refresh tracking branches when needed
git-gui: Better handling of detached HEAD
git-gui: Refactor our ui_status_value update technique
git-gui: Refactor branch switch to support detached head
git-gui: Unabbreviate commit SHA-1s prior to display
git-gui: Default selection to first matching ref
git-gui: Allow double-click in checkout dialog to start checkout
git-gui: Extract blame viewer status bar into mega-widget
git-gui: Change the main window progress bar to use status_bar
git-gui: Show a progress meter for checking out files
git-gui: Always use absolute path to all git executables
git-gui: Correct gitk installation location
git-gui: Assume unfound commands are known by git wrapper
git-gui: Treat `git version` as `git --version`
git-gui: Perform our own magic shbang detection on Windows
git-gui: Teach console widget to use git_read
git-gui: Improve the Windows and Mac OS X shortcut creators
git-gui: Paper bag fix for Cygwin shortcut creation
git-gui: Use sh.exe in Cygwin shortcuts
git-gui: Include a space in Cygwin shortcut command lines
Support wholesale directory renames in fast-import
git-gui: Change prior tree SHA-1 verification to use git_read
Steffen Prohaska (1):
filter-branch: added missing warn function
Steven Walter (1):
Documentation for git-log --follow
Sven Verdoolaege (2):
git-submodule: provide easy way of adding new submodules
git-clone: fetch possibly detached HEAD over dumb http
Uwe Kleine-König (2):
stash: end commit log with a newline
repack: don't report "Nothing new to pack." if -q is given
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-07-13 6:06 ` What's in git.git Junio C Hamano
@ 2007-07-28 8:47 ` Junio C Hamano
2007-07-28 8:56 ` David Kastrup
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-07-28 8:47 UTC (permalink / raw)
To: git
It's been a while since I sent this the last time.
We are nearing 1.5.3 final; I pulled gitk updates tonight, and
expect git-gui updates to 0.8.0 over the weekend. There are a
handful trivial fixes since 1.5.3-rc3.
I am hoping one topic (bs/lock) to graduate from 'next' and
another from nowhere (js/worktree) before 1.5.3-rc4, probably by
mid next-week.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Julian Phillips (1):
Force listingblocks to be monospaced in manpages
Junio C Hamano (1):
Do not expect unlink(2) to fail on a directory.
* The 'master' branch has these since the last announcement
in addition to the above.
Adam Roben (1):
Add GIT_EDITOR environment and core.editor configuration variables
Alex Riesen (1):
Fix git-rebase -i to allow squashing of fast-forwardable commits
Alexandre Julliard (2):
git.el: Support for incremental status updates.
git.el: Pass an explicit argument to enable smerge-mode.
Brian Gernhardt (1):
Document commit.template configuration variable.
Carlos Rica (1):
Rename read_pipe() with read_fd() and make its buffer
nul-terminated.
David Kastrup (2):
contrib/emacs/Makefile: Also install .el files.
Documentation/gitignore.txt: Fix the seriously misleading priority
explanation
Emil Medve (1):
Use $(RM) in Makefiles instead of 'rm -f'
Eric Wong (2):
git-svn: remove leading slashes from fetch lines in the generate
config
git-svn: fix commiting renames over DAV with funky file names
Francis Moreau (1):
Fix git-branch documentation when using remote refs
Greg KH (1):
make git-send-email.perl handle email addresses with no names when
Email::Valid is present
Jakub Narebski (3):
gitweb cleanup: Move @diff_opts declaration earlier
gitweb: Fix support for legacy gitweb config for snapshots
gitweb: More detailed error messages for snapshot format
Jim Meyering (2):
git-cvsserver: detect/diagnose write failure, etc.
pretty-options.txt: tiny doc fix
Johannes Schindelin (13):
filter-branch: get rid of "set -e"
rebase -i: call editor just once for a multi-squash
fsck --lost-found: write blob's contents, not their SHA-1
mailinfo: fix 'fatal: cannot convert from utf-8 to utf-8'
Shut "git rebase -i" up when no --verbose was given
rebase -i: exchange all "if [ .. ]" by "if test .."
filter-branch: Big syntax change; support rewriting multiple refs
Teach revision machinery about --no-walk
git log -g: Complain, but do not fail, when no reflogs are there
Teach approxidate() to understand "never"
git am: skip pine's internal folder data
rebase -i: fix overzealous output redirection
rebase -i: fix interrupted squashing
Josh Triplett (1):
Remove useless uses of cat, and replace with filename arguments
Junio C Hamano (24):
Make show_rfc2822_date() just another date output format.
Wire new date formats to --date=<format> parser.
Document new --date=<format>
Add contrib/stats/mailmap.pl script
Update .mailmap
Documentation/git-commit-tree: remove description of a nonexistent
limitation
GIT v1.5.3-rc2
Update INSTALL
Fix VISUAL/EDITOR preference order in Documentation/config.txt.
Synonyms: -i == --regexp-ignore-case, -E == --extended-regexp
Mark user-manual as UTF-8
user-manual: fix typolets.
t9200: Be careful when checking CVS/Entries
GIT 1.5.3-rc3
Make sure git-stash works from subdirectory.
gitweb: fix broken snapshot
git-submodule module_name: avoid using unwieldy "value_regexp"
feature.
git-submodule: remove redundant call to git-describe
When locking in a symlinked repository, try to lock the original.
git_mkstemp(): be careful not to overflow the path buffer.
Update description of -z option.
git-stash: do not remove a ref by hand.
Fix git-stash apply --index
git-stash apply --index: optimize postprocessing
Kumar Gala (1):
send-email: Update regex parsing for pine aliases
Linus Torvalds (2):
Do a better job at guessing unknown character sets
Fix up duplicate parents removal
Marco Costalba (1):
Avoid to duplicate commit message when is not encoded
Marius Storm-Olsen (1):
Fix git-p4 on Windows to not use the Posix sysconf function.
Mark Levedahl (1):
gitk: Ignore ctrl-z as EOF on windows
Matt McCutchen (1):
gitweb: snapshot cleanups & support for offering multiple formats
Matthieu Moy (1):
More permissive "git-rm --cached" behavior without -f.
Nanako Shiraishi (2):
Document "git stash message..."
git-stash: Make sure reflog is created for refs/stash
Nguyễn Thái Ngọc Duy (1):
git-write-tree should not crash if prefix does not exist
Paul Mackerras (5):
gitk: Fix bug introduced by previous commit
gitk: Show changes in index and changes in working directory
separately
gitk: Make the fake commit for the index changes green rather than
magenta
gitk: Wait for the window to become visible after creating it
gitk: Fix bugs in the Find function
Peter Hagervall (1):
Make every builtin-*.c file #include "builtin.h"
René Scharfe (2):
filter-branch: fix dash complaining about "Missing '))'"
cleanup unpack-trees.c: shrink struct tree_entry_list
Richard MUSIL (1):
git-svn: Minimalistic patch which allows svn usernames with
space(s).
Robin Rosenberg (3):
Support output ISO 8601 format dates
cvsexportcommit: avoid racy CVS problem.
Document --unified/-U option
Scott Lamb (2):
git-p4: use subprocess in p4CmdList
git-p4: input to "p4 files" by stdin instead of arguments
Sean Estabrooks (3):
Remove "WITH_P4IMPORT" knob from the Makefile
Remove p4 rpm from git.spec.in.
Demote git-p4import to contrib status.
Shawn O. Pearce (3):
Correct trivial typo in fast-import documentation
Teach fast-import to recursively copy files/directories
gitk: Bind keyboard actions to the command key on Mac OS
Simon Hausmann (4):
git-p4: Cleanup, make listExistingP4Branches a global function for
later use.
git-p4: Fix upstream branch detection for submit/rebase with
multiple branches.
git-p4: Cleanup, used common function for listing imported p4
branches
git-p4: Fix p4 user cache population on Windows.
Stephen Rothwell (1):
send-email: discard blank around address in extract_valid_address
as well.
Steven Grimm (2):
Document how to tell git to not launch a pager
Teach git-commit about commit message templates.
Sven Verdoolaege (2):
lockfile.c: schedule remove_lock_file only once.
unpack-trees.c: assume submodules are clean during check-out
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-28 8:47 ` What's in git.git (stable) Junio C Hamano
@ 2007-07-28 8:56 ` David Kastrup
2007-07-28 9:02 ` Junio C Hamano
2007-07-28 9:35 ` David Kastrup
2007-07-28 12:28 ` Thomas Glanzmann
2007-08-07 6:22 ` Junio C Hamano
2 siblings, 2 replies; 601+ messages in thread
From: David Kastrup @ 2007-07-28 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> It's been a while since I sent this the last time.
>
> We are nearing 1.5.3 final; I pulled gitk updates tonight, and
> expect git-gui updates to 0.8.0 over the weekend. There are a
> handful trivial fixes since 1.5.3-rc3.
I'd like to see some changes for mergetool's Emacs support: in
moderately current versions of Emacs and XEmacs, ediff is a much
preferable tool to emerge.
Also, the mergetool determines when to use emerge for merging by
looking at the EDITOR/VISUAL variables. While it recognizes the
presence of "emacsclient" and "gnuclient" there for offering the
emerge tool, it does not actually use those settings for calling
Emacs/XEmacs. If you use the desktop package, this means that you get
a bear of a startup time while a _new_ instance of Emacs gets loaded
against the wishes of the setup, and the command line parameters will
be interpreted relatively to the last file restored into the desktop
rather than the current directory (arguably a bug in the desktop
package which I plan to fix eventually, but in the meantime the
current package is farspread).
I'll try to come up with a fix this weekend if nobody beats me to it.
As it stands, the mergetool is somewhere between subpar and unusable
by default for a considerable number of Emacs users.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-28 8:56 ` David Kastrup
@ 2007-07-28 9:02 ` Junio C Hamano
2007-07-28 9:35 ` David Kastrup
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-07-28 9:02 UTC (permalink / raw)
To: David Kastrup; +Cc: git, Theodore Ts'o
David Kastrup <dak@gnu.org> writes:
> I'd like to see some changes for mergetool's Emacs support: in
> moderately current versions of Emacs and XEmacs, ediff is a much
> preferable tool to emerge.
Between ediff and emerge, I think Ted gave a well thought out
analysis on the list earlier, so you might want to consider the
issues he raised if/when you tackle this.
This is late in the game, however, so your change probably won't
be merged before I can tag 1.5.3 final, but I'd expect that a
better Emacs support will be widely welcomed.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-28 8:56 ` David Kastrup
2007-07-28 9:02 ` Junio C Hamano
@ 2007-07-28 9:35 ` David Kastrup
2007-07-29 3:16 ` Theodore Tso
1 sibling, 1 reply; 601+ messages in thread
From: David Kastrup @ 2007-07-28 9:35 UTC (permalink / raw)
To: git
David Kastrup <dak@gnu.org> writes:
[...]
> If you use the desktop package, this means that you get a bear of a
> startup time while a _new_ instance of Emacs gets loaded against the
> wishes of the setup, and the command line parameters will be
> interpreted relatively to the last file restored into the desktop
> rather than the current directory (arguably a bug in the desktop
> package which I plan to fix eventually, but in the meantime the
> current package is farspread).
I can't reproduce anything similar outside of mergetool, so it appears
more likely that mergetool is passing wrong relative file names.
Have to leave now for the day.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-28 9:35 ` David Kastrup
@ 2007-07-29 3:16 ` Theodore Tso
2007-07-29 9:05 ` David Kastrup
2007-07-29 11:27 ` Johannes Schindelin
0 siblings, 2 replies; 601+ messages in thread
From: Theodore Tso @ 2007-07-29 3:16 UTC (permalink / raw)
To: David Kastrup; +Cc: git
On Sat, Jul 28, 2007 at 11:35:40AM +0200, David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > If you use the desktop package, this means that you get a bear of a
> > startup time while a _new_ instance of Emacs gets loaded against the
> > wishes of the setup, and the command line parameters will be
> > interpreted relatively to the last file restored into the desktop
> > rather than the current directory (arguably a bug in the desktop
> > package which I plan to fix eventually, but in the meantime the
> > current package is farspread).
>
> I can't reproduce anything similar outside of mergetool, so it appears
> more likely that mergetool is passing wrong relative file names.
See my recent posting on this issue. The problem is that the desktop
package fundamentally changes how emacs behaves when it starts up.
And in order to fix it we will need to change git-mergetool to do an
"emacs --version", parse the version number, and then start changing
how it calls emacs (and if you *really* want to use emacsclient,
whether it can use emacsclient) based on the version of emacs which is
installed as the default for the user. It's going to be really messy,
and fundamentally, emacs as used by people who are using the desktop
package really wants to be the center of the universe, instead of
something which gets called to run a "merge application". Testing to
make sure this works on every single emacs version/variant, and every
single user's weird-sh*t startup scripts isn't something I'm looking
forward to.
So I really am beginning to think the right answer is to give up on
using git-mergetool to support anything other than basic emacs users
(who just use emacs as an editor, what a concept), and for the H4rd
C0re emacs l33t, they can use a contrib/git-mergetool.el that does
everything inside emacs. Since these are the people who want emacs to
be their desktop, their shell, *and* their window manager, they will
probably be happier that way....
- Ted
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-29 3:16 ` Theodore Tso
@ 2007-07-29 9:05 ` David Kastrup
2007-07-29 16:40 ` Theodore Tso
2007-07-29 11:27 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: David Kastrup @ 2007-07-29 9:05 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
Theodore Tso <tytso@mit.edu> writes:
> So I really am beginning to think the right answer is to give up on
> using git-mergetool to support anything other than basic emacs users
> (who just use emacs as an editor, what a concept),
In contrast, you are trying to support only people by using Emacs
_not_ as an editor, but as a mergetool under the control of git.
That's a mistake.
> and for the H4rd C0re emacs l33t, they can use a
> contrib/git-mergetool.el that does everything inside emacs. Since
> these are the people who want emacs to be their desktop, their
> shell, *and* their window manager, they will probably be happier
> that way....
Sorry, but you are way off here. The normal, standard use of Emacs is
to start it once and do everything in it. Its startup time is such
that other uses are not feasible.
(info "(emacs) Entering Emacs")
Many editors are designed to edit one file. When done with
that file, you exit the editor. The next time you want to edit a
file, you must start the editor again. Working this way, it is
convenient to use a command-line argument to say which file to
edit.
However, killing Emacs after editing one each and starting it
afresh for the next file is both unnecessary and harmful, since it
denies you the full power of Emacs. Emacs can visit more than one
file in a single editing session, and that is the right way to use
it. Exiting the Emacs session loses valuable accumulated context,
such as the kill ring, registers, undo history, and mark ring.
These features are useful for operating on multiple files, or even
continuing to edit one file. If you kill Emacs after each file,
you don't take advantage of them.
The recommended way to use GNU Emacs is to start it only once,
just after you log in, and do all your editing in the same Emacs
session. Each time you edit a file, you visit it with the
existing Emacs, which eventually has many files in it ready for
editing. Usually you do not kill Emacs until you are about to log
out. *Note Files::, for more information on visiting more than
one file.
To edit a file from another program while Emacs is running, you
can use the `emacsclient' helper program to open a file in the
already running Emacs. *Note Emacs Server::.
So git's mergetool philosophy is currently _straight_ set against the
way Emacs is designed to work.
One solution would be to call emacs -q in order to weed out users with
the impunity of customizing Emacs to suit their needs rather than
those of git.
But the sanest is really to call Emacs just the way the user
configured $EDITOR to call it and pass it an initial merge command.
And then decide from the results on the disk what to further do.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-29 9:05 ` David Kastrup
@ 2007-07-29 16:40 ` Theodore Tso
0 siblings, 0 replies; 601+ messages in thread
From: Theodore Tso @ 2007-07-29 16:40 UTC (permalink / raw)
To: David Kastrup; +Cc: git
On Sun, Jul 29, 2007 at 11:05:42AM +0200, David Kastrup wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > So I really am beginning to think the right answer is to give up on
> > using git-mergetool to support anything other than basic emacs users
> > (who just use emacs as an editor, what a concept),
>
> In contrast, you are trying to support only people by using Emacs
> _not_ as an editor, but as a mergetool under the control of git.
> That's a mistake.
The whole *point* of git-mergetool is to automatically call merge
tools so you can do three-way merges under the control of git.
If you just want an *editor* then you can just edit the files that are
listed as being in conflict after a failed merge or after running "git
status". You can do that today without using git-mergetool at all!
> Sorry, but you are way off here. The normal, standard use of Emacs is
> to start it once and do everything in it. Its startup time is such
> that other uses are not feasible.
Huh? The startup time of running emacs for me is well under a second
(and I have a 20k ~/.emacs.el file that loads a number of other
files). I'm sure if you put enough *crap* into your .emacs.el file,
you can make it take a huge amount of time, but I suspect your idea of
what is "normal" for emacs is more than a little skewed.
> So git's mergetool philosophy is currently _straight_ set against the
> way Emacs is designed to work.
So don't use git-mergetool. Like I said, I suspect the right answer
is contrib/git-mergetool.el, and do everything inside emacs. If you
are as extreme as someone who pulls in gazillions of emacs packages,
and you are using emacs as a desktop, a shell, and a window manager,
then you can probably do much better using a pure emacs lisp merge
system.
Git mergetool is fundamentally designed to work with tools like meld,
kdiff3, xxdiff, tkdiff, etc. These are all merge tools, and they work
a certain way. They expect, and need, to be driven a certain way. If
you insist on following a fundamentally different paradigm, then past
a certain point git-mergetool is not going to make you happy no matter
what I can do. The point is, git-mergetool does *need* to do know
when you are done doing a merge, and it needs to know if you've
decided to abandon a merge. Right now ediff doesn't fit well into
that paradigm. And that's fundamentally ediff's fault; we can do some
kludgery on the git-mergetool side, but the end result will always be
unsatisfactory, and will require that the person using it to *know*
that it is done.
I, personally, don't feel like trying to twist git-mergetool into
doing the right thing depending on whether you have emacs21, emacs22,
emacs23-snapshot, whether or not the desktop package is in use,
whether or not the user is using emacsclient or not, yadda, yadda,
yaddda. If you want to take a crack at doing *all* of that mess, and
provide a complete solution, send me patches and I'll look at them.
I think it will add a huge amount of *crap* into git-mergetool in
order to support all possible use cases (I'm not interesting in
putting in hackery just for your favorite use case, if it causes other
users to scratch their heads in befuddlement and confusion), but feel
free to prove me wrong.
As someone who has used emacs for over two decades, and have written
very sophisticated emacs lisp code during nearly all of those 21 years
(1986--2007; my first use of emacs was on a Vax 750 running BSD 4.3
--- if you want to talk about emacs taking a long time to start up, I
remember what it was like 20 years ago), I'm pretty well aware of what
you can and can not do in emacs, and I think I can say with fairly
good authority that for the amount of effort it would take to try to
get git-mergetool to hack around all of these different cases, writing
git-mergetool.el will probably be easier, and result in a cleaner,
better integration with people who like to live their entire lives in
a single emacs session.
- Ted
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-29 3:16 ` Theodore Tso
2007-07-29 9:05 ` David Kastrup
@ 2007-07-29 11:27 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-07-29 11:27 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
Hi,
On Sat, 28 Jul 2007, Theodore Tso wrote:
> So I really am beginning to think the right answer is to give up on
> using git-mergetool to support anything other than basic emacs users
> (who just use emacs as an editor, what a concept), and for the H4rd C0re
> emacs l33t, they can use a contrib/git-mergetool.el that does everything
> inside emacs. Since these are the people who want emacs to be their
> desktop, their shell, *and* their window manager, they will probably be
> happier that way....
Well, maybe not happier. But at least they will be forced to write a
patch (if they really want to use git _their_ way, and they'll have to
defend their patch if they break all other people's work flow), instead of
writing a lot of long and useless emails.
IOW I do not think "we" have to do something about it.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-07-28 8:47 ` What's in git.git (stable) Junio C Hamano
2007-07-28 8:56 ` David Kastrup
@ 2007-07-28 12:28 ` Thomas Glanzmann
2007-08-07 6:22 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Thomas Glanzmann @ 2007-07-28 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
Hello Junio,
git HEAD compiles under 'Solaris 8/Forte 11' and 'Solaris 10/Forte 12'
for me.
Thomas
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-07-28 8:47 ` What's in git.git (stable) Junio C Hamano
2007-07-28 8:56 ` David Kastrup
2007-07-28 12:28 ` Thomas Glanzmann
@ 2007-08-07 6:22 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-08-07 6:22 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last
announcement, which are all included in 'master' as well.
Because 1.5.3 is just around the corner, I think it is
pointless to do 1.5.2.5 from here, though.
Christian Couder (1):
rev-list --bisect: fix allocation of "int*" instead of "int".
Junio C Hamano (1):
setup.c:verify_non_filename(): don't die unnecessarily while
disambiguating
Linus Torvalds (1):
apply: remove directory that becomes empty by renaming the last
file away
* The 'master' branch has these since 1.5.3-rc4.
Adam Roben (1):
Documentation/git-svn: how to clone a git-svn-created repository
Gerrit Pape (1):
git-am: initialize variable $resume on startup
J. Bruce Fields (4):
user-manual: update for new default --track behavior
user-manual: mention git-gui
documentation: use the word "index" in the git-add manual page
documentation: use the word "index" in the git-commit man page
Jakub Narebski (1):
gitweb: Fix handling of $file_name in feed generation
Johannes Schindelin (1):
checkout-index needs a working tree
Junio C Hamano (8):
git-completion: add "git stash"
INSTALL: add warning on docbook-xsl 1.72 and 1.73
unpack-trees.c: assume submodules are clean during check-out
Fix install-doc-quick target
user-manual: mention git stash
setup.c:verify_non_filename(): don't die unnecessarily while
disambiguating
pager: find out pager setting from configuration
Fix "make GZ=1 quick-install-doc"
Jyotirmoy Bhattacharya (1):
Fixed git-push manpage
Linus Torvalds (1):
apply: remove directory that becomes empty by renaming the last
file away
Randal L. Schwartz (1):
add "test-absolute-path" to .gitignore
Shawn O. Pearce (1):
Document GIT_SSH environment variable alongside other variables
Uwe Kleine-König (1):
send-email: teach sanitize_address to do rfc2047 quoting
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-05-09 8:46 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-05-09 8:46 UTC (permalink / raw)
To: git
v1.5.1.4 is out.
Thanks to HPA who installed libdbi-dbd interface to sqlite on
kernel.org machines, Frank's cvsserver tests are now in
'master', along with updates to gitweb and git-gui. I've thrown
in the diff-tree memory optimization we discussed in the OOo
thread as well.
I haven't tagged the tip of the 'master', but this is pretty
much 1.5.2-rc3 -- I may tag it tomorrow with a few more fixes I
noticed are needed while I was reviewing the list traffic (I
updated todo:TODO with them).
v1.5.2 final is scheduled for sometime late next week, hopefully
with git-gui v0.7.0 final.
----------------------------------------------------------------
* The 'maint' branch is now at 1.5.1.4, with these fixes since
the last announcement.
Amos Waterland (1):
wcwidth redeclaration
J. Bruce Fields (7):
user-manual: more discussion of detached heads, fix typos
user-manual: add section ID's
user-manual: clean up fast-forward and dangling-objects sections
user-manual: fix .gitconfig editing examples
user-manual: miscellaneous editing
user-manual: stop deprecating the manual
user-manual: fix clone and fetch typos
Jeff King (1):
Documentation: don't reference non-existent 'git-cvsapplycommit'
Junio C Hamano (1):
GIT v1.5.1.4
Paul Mackerras (1):
gitk: Allow user to choose whether to see the diff, old file, or new file
Quy Tonthat (1):
Add howto files to rpm packages.
Shawn O. Pearce (1):
git-gui: Allow spaces in path to 'wish'
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Use GIT_OBJECT_DIR for temporary files of pack-objects
Frank Lichtenheld (1):
cvsserver: Add test cases for git-cvsserver
Jakub Narebski (6):
gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line
gitweb: Add combined diff support to git_difftree_body
gitweb: Add combined diff support to git_patchset_body
gitweb: Make it possible to use pre-parsed info in git_difftree_body
gitweb: Show combined diff for merge commits in 'commitdiff' view
gitweb: Show combined diff for merge commits in 'commit' view
Junio C Hamano (5):
diff: release blobs after generating textual diff.
diff.c: do not use a separate "size cache".
diff -M: release the preimage candidate blobs after rename detection.
diff -S: release the image after looking for needle in it
Update documentation links to point at 1.5.1.4
Matthieu Moy (2):
Document git add -u introduced earlier.
Added a reference to git-add in the documentation for git-update-index
Michael Spang (3):
dir.c: Omit non-excluded directories with dir->show_ignored
t7300: Basic tests for git-clean
Fix minor documentation errors
Shawn O. Pearce (17):
git-gui: Correctly handle UTF-8 encoded commit messages
git-gui: Include the subject in the status bar after commit
git-gui: Warn users before making an octopus merge
git-gui: Correct line wrapping for too many branch message
git-gui: Cleanup common font handling for font_ui
git-gui: Use option database defaults to set the font
git-gui: Refactor to use our git proc more often
git-gui: Track our own embedded values and rebuild when they change
git-gui: Refactor into multiple files to save my sanity
git-gui: Move console procs into their own namespace
git-gui: Allow vi keys to scroll the diff/blame regions
git-gui: Move merge support into a namespace
git-gui: Show all possible branches for merge
git-gui: Include commit id/subject in merge choices
git-gui: Use vi-like keys in merge dialog
Remove duplicate exports from Makefile
Use .git/MERGE_MSG in cherry-pick/revert
Theodore Ts'o (2):
Add pack.depth option to git-pack-objects.
Increase pack.depth default to 50
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-04-16 1:27 Junio C Hamano
2007-04-18 23:58 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-16 1:27 UTC (permalink / raw)
To: git
Perhaps we would need 1.5.1.2 to push out a few accumulated
small fixes on 'maint'.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.1.1.
Alex Riesen (2):
Use rev-list --reverse in git-rebase.sh
Document -g (--walk-reflogs) option of git-log
Eygene Ryabinkin (2):
Teach gitk to use the user-defined UI font everywhere.
Improve look-and-feel of the gitk tool.
Frank Lichtenheld (4):
config.txt: Document gitcvs.allbinary
config.txt: Document core.autocrlf
config.txt: Change pserver to server in description of gitcvs.*
config.txt: Fix grammatical error in description of http.noEPSV
Jim Meyering (1):
sscanf/strtoul: parse integers robustly
Junio C Hamano (1):
Do not default to --no-index when given two directories.
Linus Torvalds (1):
git-quiltimport complaining yet still working
Matthias Lederhofer (1):
handle_options in git wrapper miscounts the options it handled.
Michael Spang (1):
git-blame: Fix overrun in fake_working_tree_commit()
* The 'master' branch has these since the last announcement
in addition to the above.
Frank Lichtenheld (2):
gitweb: Allow forks with project list file
gitweb: Allow configuring the default projects order and add order 'none'
Jim Meyering (1):
sscanf/strtoul: parse integers robustly
Junio C Hamano (5):
Add %m to '--pretty=format:'
Refactor patch-id filtering out of git-cherry and git-format-patch.
git-log --cherry-pick A...B
Documentation: --cherry-pick
Fix git {log,show,...} --pretty=email
Luiz Fernando N. Capitulino (2):
ident.c: Use const qualifier for 'struct passwd' parameters
ident.c: Use size_t (instead of int) to store sizes
René Scharfe (1):
git-archive: make tar the default format
Robin H. Johnson (2):
Add custom subject prefix support to format-patch (take 3)
Add testcase for format-patch --subject-prefix (take 3)
Shawn O. Pearce (1):
Don't yap about merge-subtree during make
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-16 1:27 Junio C Hamano
@ 2007-04-18 23:58 ` Junio C Hamano
2007-04-22 6:22 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-18 23:58 UTC (permalink / raw)
To: git
Accumulated fixes on 'maint' are mostly documentation updates.
I will do a 1.5.1.2 probably this weekend, when I find time.
On 'master' are Frank's cvsserver updates to use DBI to allow
backends other than sqlite. There also is an update to
merge-recursive to make it saner for merges that involves a
directory changing to a file (or vice versa).
I did not hear anything positive nor negative while they were on
'next', so if you have been using cvsserver or merge and this
breaks them for you, you had it coming. At least you can keep
both pieces ;-).
But more seriously, hopefully no news was a good news. There
are also other minor new features and enhancements on 'master'.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Fix overwriting of files when applying contextually independent diffs
Andrew Ruder (4):
Update git-am documentation
Update git-applymbox documentation
Update git-apply documentation
Update git-annotate/git-blame documentation
Carlos Rica (1):
Use const qualifier for 'sha1' parameter in delete_ref function
Eric Wong (3):
git-svn: respect lower bound of -r/--revision when following parent
git-svn: quiet some warnings when run only with --version/--help
git-svn: don't allow globs to match regular files
Frank Lichtenheld (1):
git-shortlog: Fix two formatting errors in asciidoc documentation
Gerrit Pape (2):
variable $projectdesc needs to be set before checking against unchanged default.
Have sample update hook not refuse deleting a branch through push.
J. Bruce Fields (7):
Documentation: minor edits of git-lost-found manpage
Documentation: clarify git-checkout -f, minor editing
Documentation: clarify track/no-track option.
user-manual: fix discussion of default clone
user-manual: detached HEAD
user-manual: start revising "internals" chapter
user-manual: use detached head when rewriting history
Junio C Hamano (1):
Start preparing for 1.5.1.2
Shawn O. Pearce (1):
git-gui: Brown paper bag fix division by 0 in blame
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Fix t4201: accidental arithmetic expansion
Fix permissions on test scripts
Andrew Ruder (1):
Add policy on user-interface changes
Christian Couder (2):
Bisect: simplify "bisect start" logging.
Bisect: rename "t/t6030-bisect-run.sh" to "t/t6030-bisect-porcelain.sh".
Eygene Ryabinkin (4):
Allow wish interpreter to be defined with TCLTK_PATH
Teach git-gui to use the user-defined UI font everywhere.
Improve look-and-feel of the git-gui tool.
Do not break git-gui messages into multiple lines.
Frank Lichtenheld (12):
cvsserver: Introduce new state variable 'method'
cvsserver: Handle three part keys in git config correctly
cvsserver: Allow to override the configuration per access method
cvsserver: Make the database backend configurable
cvsserver: Abort if connect to database fails
cvsserver: Use DBI->table_info instead of DBI->tables
cvsserver: Corrections to the database backend configuration
cvsserver: Add asciidoc documentation for new database backend configuration
cvsserver: Allow to "add" a removed file
cvsserver: Reword documentation on necessity of write access
cvsserver: Document the GIT branches -> CVS modules mapping more prominently
config.txt: Add gitcvs.db* variables
Johannes Schindelin (1):
Use print_wrapped_text() in shortlog
Junio C Hamano (9):
shortlog -w: make wrap-line behaviour optional.
t1000: fix case table.
Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()
merge-recursive: do not barf on "to be removed" entries.
merge-recursive: handle D/F conflict case more carefully.
t3030: merge-recursive backend test.
send-email: do not leave an empty CC: line if no cc is present.
git-gui: Honor TCLTK_PATH if supplied
Update draft release notes for 1.5.2 with accumulated changes.
Linus Torvalds (2):
Add a generic "object decorator" interface, and make object refs use it
Add support for "commit name decorations" to log family of commands
Michael S. Tsirkin (1):
Display the subject of the commit just made.
Shawn O. Pearce (3):
Always bind the return key to the default button
git-gui: Display the directory basename in the title
Revert "Allow wish interpreter to be defined with TCLTK_PATH"
Steven Grimm (3):
Add --quiet option to suppress output of "rm" commands for removed files.
git-rm: Trivial fix for a comment typo.
Add --ignore-unmatch option to exit with zero status when no files are removed.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-18 23:58 ` Junio C Hamano
@ 2007-04-22 6:22 ` Junio C Hamano
2007-04-23 7:04 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-22 6:22 UTC (permalink / raw)
To: git
The latest maintenance release v1.5.1.2 is out.
Tonight's 'master' contains 64-bit index, core subproject
support, and gitattributes (but not the controversial "filter"
part). As I promised I'd do something about attributes some
time ago (I think it was during v1.5.1 stabilization period), I
am reasonably happy with the state of 'master' right now. The
other two major topics are also nice, unexpected bonus toward
v1.5.2 from my point of view.
Please expect stabilization cycle for v1.5.2 to start soon.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last
announcement; these are all contained in v1.5.1.2, the latest
maintenance release.
Andrew Ruder (4):
Update git-archive documentation
Update git-cherry-pick documentation
Fix unmatched emphasis tag in git-tutorial
Update git-config documentation
Andy Whitcroft (1):
fix up strtoul_ui error handling
Eric Wong (1):
perl: install private Error.pm if the site version is older than our own
Junio C Hamano (2):
git-clone: fix dumb protocol transport to clone from pack-pruned ref
GIT 1.5.1.2
Sam Vilain (1):
git-tar-tree: complete deprecation conversion message
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Tests for core subproject support
Simplify calling of CR/LF conversion routines
Alexandre Julliard (1):
git.el: Add a commit description to the reflog.
Aneesh Kumar K.V (1):
gitview: annotation support
Brian Gernhardt (1):
Remove case-sensitive file in t3030-merge-recursive.
James Bowes (1):
Document git-check-attr
Julian Phillips (1):
refs.c: add a function to sort a ref list, rather then sorting on add
Junio C Hamano (30):
git-fetch--tool pick-rref
git-fetch: use fetch--tool pick-rref to avoid local fetch from alternate
Add basic infrastructure to assign attributes to paths
Define 'crlf' attribute.
Teach 'diff' about 'diff' attribute.
Fix 'crlf' attribute semantics.
Fix 'diff' attribute semantics.
Makefile: add patch-ids.h back in.
attribute macro support
Define a built-in attribute macro "binary".
Change attribute negation marker from '!' to '-'.
Make sure quickfetch is not fooled with a previous, incomplete fetch.
Allow more than true/false to attributes.
merge-recursive: separate out xdl_merge() interface.
Allow specifying specialized merge-backend per path.
Add a demonstration/test of customized merge.
Custom low-level merge driver support.
Allow the default low-level merge driver to be configured.
Custom low-level merge driver: change the configuration scheme.
Allow low-level driver to specify different behaviour during internal merge.
Fix funny types used in attribute value representation
Counto-fix in merge-recursive
Simplify code to find recursive merge driver.
Documentation: support manual section (5) - file formats.
Update 'crlf' attribute semantics.
Document gitattributes(5)
git-add -u: match the index with working tree.
Fix bogus linked-list management for user defined merge drivers.
convert.c: restructure the attribute checking part.
lockfile: record the primary process.
Linus Torvalds (21):
diff-lib: use ce_mode_from_stat() rather than messing with modes manually
Avoid overflowing name buffer in deep directory structures
Add 'resolve_gitlink_ref()' helper function
Add "S_IFDIRLNK" file mode infrastructure for git links
Teach "fsck" not to follow subproject links
Teach core object handling functions about gitlinks
Fix thinko in subproject entry sorting
Teach directory traversal about subprojects
Teach git-update-index about gitlinks
Don't show gitlink directories when we want "other" files
Teach git list-objects logic not to follow gitlinks
Teach "git-read-tree -u" to check out submodules as a directory
Fix gitlink index entry filesystem matching
Teach git list-objects logic to not follow gitlinks
Teach "git-read-tree -u" to check out submodules as a directory
Fix some "git ls-files -o" fallout from gitlinks
Expose subprojects as special files to "git diff" machinery
Use proper object allocators for unknown object nodes too
Clean up object creation to use more common code
Fix working directory errno handling when unlinking a directory
Fix a copy-n-paste bug in the object decorator code.
Nicolas Pitre (27):
get rid of num_packed_objects()
make overflow test on delta base offset work regardless of variable size
add overflow tests on pack offset variables
compute a CRC32 for each object as stored in a pack
compute object CRC32 with index-pack
pack-objects: learn about pack index version 2
index-pack: learn about pack index version 2
sha1_file.c: learn about index version 2
show-index.c: learn about index v2
pack-redundant.c: learn about index v2
allow forcing index v2 and 64-bit offset treshold
validate reused pack data with CRC when possible
simple random data generator for tests
use test-genrandom in tests instead of /dev/urandom
tests for various pack index features
clean up add_object_entry()
pack-objects: optimize preferred base handling a bit
pack-objects: equal objects in size should delta against newer objects
pack-objects: rework check_delta_limit usage
pack-objects: clean up list sorting
pack-objects: get rid of reuse_cached_pack
pack-objects: get rid of create_final_object_list()
pack-objects: make in_pack_header_size a variable of its own
add get_size_from_delta()
pack-objects: better check_object() performances
pack-objects: remove obsolete comments
document --index-version for index-pack and pack-objects
Shawn O. Pearce (2):
Contribute a fairly paranoid update hook
Kill the useless progress meter in merge-recursive
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-22 6:22 ` Junio C Hamano
@ 2007-04-23 7:04 ` Junio C Hamano
2007-04-27 8:34 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-23 7:04 UTC (permalink / raw)
To: git
Together with fixes to pack-objects mode bits gotcha that caused
quite a traffic on the list this morning, and crlf conversion
bug from Alex, I've fast-tracked a few topics to 'master' tonight:
- Nico's progress meter clean-up.
- My custom diff driver in gitattributes series.
By "fast-track", I mean there might still be bugs in the code
but there do not seem to be anything contentious in the design,
and I trust the people who can fix possible breakages are
responsive. I think "ident" attribute to expand "$ident$" in
blobs is probably less controversial as it is a stateless
transformation, but I left it out for now.
The tip of 'master' tonight is v1.5.2-rc0. I am reasonably sure
that I have missed a few topics that we saw/reviewed patches for
the past several days. Please do not get discouraged as I have
not necessarily rejected them; I was just busy whipping v1.5.1.2
and the 'master' branch into shape tonight. Please discuss the
patches that are missing from tonight's 'master' for possible
inclusion in the coming few days, and then let's declare feature
freeze by the end of the week with v1.5.2-rc1. After that, the
usual rules for stabilization period applies (no new features,
only fixes including documentation updates).
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Fix a typo in crlf conversion code
Fix crash in t0020 (crlf conversion)
Junio C Hamano (8):
Update documentation links to point at v1.5.1.2
Documentation/Makefile: fix section (5) installation
Update draft release notes for v1.5.2
pack-objects: quickfix for permission modes.
Fix 'quickfix' on pack-objects.
Update tests not to assume that generated packfiles are writable.
pack-objects: make generated packfile read-only
Support 'diff=pgm' attribute
Martin Koegler (1):
gitweb: Show "no difference" message for empty diff
Nicolas Pitre (4):
common progress display support
make progress "title" part of the common progress interface
provide a facility for "delayed" progress reporting
delay progress display when checking out files
Shawn O. Pearce (1):
Cleanup variables in cat-file
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-23 7:04 ` Junio C Hamano
@ 2007-04-27 8:34 ` Junio C Hamano
2007-04-27 9:19 ` Andy Parkins
2007-04-29 18:33 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-27 8:34 UTC (permalink / raw)
To: git
We've accumulated quite a bit of fixes on 'maint', so I need to
do a 1.5.1.3 release soonish, as we will go into feature freeze
on 'master' shortly in preparation for 1.5.2.
On the 'master' front, things have been stabilizing. Modulo
documentation updates and bugfixes, I expect what we have here
tonight will be pretty much what the final 1.5.2 would look
like. I already know Shawn has plans to feed git-gui 0.6.6
updates, which should also be included in the final one.
But I might have missed or dismissed patches we have seen and
reviewed on the list recently that deserve to be in 1.5.2, so
please raise hand if you see something missing. After that,
I'll tag v1.5.2-rc1 and from there we will do the usual "no new
features, options, commands -- only fixes", which hopefully will
happen on Monday.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Adam Roben (3):
Remove usernames from all commit messages, not just when using svmprops
git-svn: Don't rely on $_ after making a function call
git-svn: Ignore usernames in URLs in find_by_url
Alex Riesen (1):
Fix handle leak in write_tree
Andrew Ruder (8):
Removing -n option from git-diff-files documentation
Document additional options for git-fetch
Update git-fmt-merge documentation
Update git-grep documentation
Update -L documentation for git-blame/git-annotate
Update git-http-push documentation
Update git-local-fetch documentation
Update git-http-fetch documentation
Brian Gernhardt (2):
Reverse the order of -b and --track in the man page.
Ignore all man sections as they are generated files.
Gerrit Pape (1):
Documentation/git-reset.txt: suggest git commit --amend in example.
Johannes Schindelin (1):
dir.c(common_prefix): Fix two bugs
Josh Triplett (2):
Fix typo in git-am: s/Was is/Was it/
Create a sysconfdir variable, and use it for ETC_GITCONFIG
Junio C Hamano (3):
Build RPM with ETC_GITCONFIG=/etc/gitconfig
applymbox & quiltimport: typofix.
Start preparing for 1.5.1.3
Robin H. Johnson (10):
Document --dry-run parameter to send-email.
Prefix Dry- to the message status to denote dry-runs.
Debugging cleanup improvements
Change the scope of the $cc variable as it is not needed outside of send_message.
Perform correct quoting of recipient names.
Validate @recipients before using it for sendmail and Net::SMTP.
Ensure clean addresses are always used with Net::SMTP
Allow users to optionally specify their envelope sender.
Document --dry-run and envelope-sender for git-send-email.
Sanitize @to recipients.
Shawn O. Pearce (1):
Actually handle some-low memory conditions
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (3):
Avoid excessive rewrites in merge-recursive
Add a test for merging changed and rename-changed branches
Ignore merged status of the file-level merge
Andy Parkins (3):
post-receive-email example hook: fastforward should have been fast_forward
post-receive-email example hook: detect rewind-only updates and output sensible message
post-receive-email example hook: sed command for getting description was wrong
Johannes Schindelin (1):
t4201: Do not display weird characters on the terminal
Josh Triplett (1):
Add clean.requireForce option, and add -f option to git-clean to override it
Junio C Hamano (9):
Move index-related variables into a structure.
Make read-cache.c "the_index" free.
Document "diff=driver" attribute
t5302: avoid using tail -c
t6030: grab commit object name as we go
Diff between two blobs should take mode changes into account now.
t/test-lib.sh: Protect ourselves from common misconfiguration
gitattributes documentation: clarify overriding
Add --date={local,relative,default}
Luiz Fernando N. Capitulino (5):
remove_subtree(): Use strerror() when possible
entry.c: Use const qualifier for 'struct checkout' parameters
read_cache_from(): small simplification
core-tutorial: minor fixes
init_buffer(): Kill buf pointer
Martin Koegler (5):
Add S_IFINVALID mode
add get_sha1_with_mode
add add_object_array_with_mode
store mode in rev_list, if <tree>:<filename> syntax is used
use mode of the tree in git-diff, if <tree>:<file> syntax is used
Nicolas Pitre (1):
add file checkout progress
OGAWA Hirofumi (1):
git-fetch: Fix "argument list too long"
Sami Farin (1):
fast-import: size_t vs ssize_t
Shawn O. Pearce (1):
Don't repack existing objects in fast-import
Uwe Kleine-König (1):
fix importing of subversion tars
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 8:34 ` Junio C Hamano
@ 2007-04-27 9:19 ` Andy Parkins
2007-04-27 14:01 ` Nicolas Pitre
2007-04-27 17:11 ` Linus Torvalds
2007-04-29 18:33 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2007-04-27 9:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
On Friday 2007 April 27, Junio C Hamano wrote:
> We've accumulated quite a bit of fixes on 'maint', so I need to
> do a 1.5.1.3 release soonish, as we will go into feature freeze
> on 'master' shortly in preparation for 1.5.2.
I am still concerned about the submodule thing - once we push a mainline
version out with the format decided, that will be that and we'll be stuck
with it. Are we _really_ sure that it's right to have a non-object hash in
the tree objects?
It's a fundamental change in the form of the tree: at the moment every hash in
the tree object represents another object in the same repository; with
gitlink as it is, that convention is broken.
Let's be really, really sure. I'm not sure a big enough fuss has been made of
the fact that this is a change of repository format. Before this you could
pretty much access any repository with any version.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 9:19 ` Andy Parkins
@ 2007-04-27 14:01 ` Nicolas Pitre
2007-04-27 15:21 ` Andy Parkins
2007-04-27 17:11 ` Linus Torvalds
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2007-04-27 14:01 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
On Fri, 27 Apr 2007, Andy Parkins wrote:
> I am still concerned about the submodule thing - once we push a mainline
> version out with the format decided, that will be that and we'll be stuck
> with it. Are we _really_ sure that it's right to have a non-object hash in
> the tree objects?
>
> It's a fundamental change in the form of the tree: at the moment every hash in
> the tree object represents another object in the same repository; with
> gitlink as it is, that convention is broken.
>
> Let's be really, really sure. I'm not sure a big enough fuss has been made of
> the fact that this is a change of repository format. Before this you could
> pretty much access any repository with any version.
I think it is reasonable to say that if you intend to work with a repo
that contains references to submodules, then you need to upgrade your
Git version. It is not like if the Git licensing fees are really
prohibitive.
Nicolas
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 14:01 ` Nicolas Pitre
@ 2007-04-27 15:21 ` Andy Parkins
0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2007-04-27 15:21 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Junio C Hamano
On Friday 2007 April 27, Nicolas Pitre wrote:
> I think it is reasonable to say that if you intend to work with a repo
> that contains references to submodules, then you need to upgrade your
> Git version. It is not like if the Git licensing fees are really
> prohibitive.
:-) Absolutely.
The case I was thinking about was when the server hosting your project doesn't
have submodule support and isn't under your direct control. For example:
kernel.org and repo.or.cz. The same is true for those people for whom the IT
department manage their central server, and aren't very helpful.
In those cases, that repository is being used as storage, it's bare, doesn't
have an index and doesn't ever checkout the files. If submodule support were
capable of being stored (not checked out) by an older git, then people can
use submodules merely if they have support on the client side.
There's also the distributions to think about - taking Debian as an example -
a lot of people stick with stable only (especially for servers) - and stable
is stuck with 1.4.4.4. It's going to be a long time before a
submodule-capable git hits Debian stable.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 9:19 ` Andy Parkins
2007-04-27 14:01 ` Nicolas Pitre
@ 2007-04-27 17:11 ` Linus Torvalds
2007-04-27 18:03 ` Andy Parkins
1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2007-04-27 17:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
On Fri, 27 Apr 2007, Andy Parkins wrote:
>
> Let's be really, really sure. I'm not sure a big enough fuss has been made of
> the fact that this is a change of repository format. Before this you could
> pretty much access any repository with any version.
I'm personally really really sure. The whole point of subprojects (at
least the way _I_ envisioned them) was to have them point to objects
outside the same repository, so it's more than just an implementation
detail, it's very much design.
And yes, of course we could have made it point to a blob inside the
superproject, and have that blob then contain a SHA1 that old versions of
git wouldn't have known to follow. But that would have been pretty hacky,
and old versions of git would _still_ have had trouble with the new
feature: at a minimum, git-fsck would always complain about the invalid
mode (and things like "git diff" would too - I think it used to just die
on unknown modes).
The "git-fsck/diff not working" thing might be seen as something that
isn't important on the server side, but I think it ends up being critial,
both for gitweb, and simply because I'd expect server side to want to
verify the projects they export too. So I do think you'd want to have a
recent git to support recent featurs.
So I think it boils down to:
- old git versions will obviously happily continue to export all normal
repositories (including the submodules themselves).
- but the actual supermodule support for embedding those submodules
really is a fundamentally new linkage, and if you want to use
supermodules, you have to have a recent enough git. Even if it's just
exporting them.
- with 1.5.2, git will be good enough to _serve_ stuff, even if it might
not be very usable for the client-side operations. So especially since
there won't be a whole lot of users (due to the client limitations), I
think it's fine to expect a "sufficiently capable" git version if you
start serving subproject content.
But, yeah, this is just my personal view of sub/superproject support, and
I've never actually _used_ it myself apart from my small test-repo thing.
Linus
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 17:11 ` Linus Torvalds
@ 2007-04-27 18:03 ` Andy Parkins
2007-04-27 18:12 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2007-04-27 18:03 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
On Friday 2007, April 27, Linus Torvalds wrote:
> I'm personally really really sure. The whole point of subprojects (at
Fair enough. I just hadn't seen very much talk about this issue and
wanted to make sure.
> trouble with the new feature: at a minimum, git-fsck would always
> complain about the invalid mode (and things like "git diff" would too
> - I think it used to just die on unknown modes).
That kind of settles it really - if neither implementation would have
worked with non-submodule git then the decision must come down to which
is technically better - and I'm persuaded that the extra layer of
indirection doesn't actually gain anything other than some extra
objects to track.
> - with 1.5.2, git will be good enough to _serve_ stuff, even if it
> might not be very usable for the client-side operations. So
>From my point of view, I don't really mind manually fetching the
submodules. I very much appreciate that I don't _have_ to have the
submodules for the superproject to continue to work.
I was actually surprised how little I'm finding I need submodule support
in the porcelain. The only slight problem at the moment is with
git-checkout; switching from a branch with the supermodule to a branch
without it and back needs a bit of hoop jumping, but nothing too
painful. All in all - success all over.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-27 18:03 ` Andy Parkins
@ 2007-04-27 18:12 ` Linus Torvalds
0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2007-04-27 18:12 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
On Fri, 27 Apr 2007, Andy Parkins wrote:
>
> I was actually surprised how little I'm finding I need submodule support
> in the porcelain. The only slight problem at the moment is with
> git-checkout; switching from a branch with the supermodule to a branch
> without it and back needs a bit of hoop jumping, but nothing too
> painful. All in all - success all over.
Heh, good to hear, but I suspect your habits may differ from other
peoples...
I agree that "git checkout" needs to have that .gitmodules thing. It
should actually be fairly straightforward, although there are subtle
issues (ie right now we can *atomically* say "cannot check out, it's
dirty" - what happens when you've already checked out five subprojects,
and the sixth one is dirty?).
"git diff --subprojects" is likely also something people will want, and
that should be _reasonably_ straigtforward.
"git merge" is the big one.
Linus
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-27 8:34 ` Junio C Hamano
2007-04-27 9:19 ` Andy Parkins
@ 2007-04-29 18:33 ` Junio C Hamano
2007-04-30 4:15 ` J. Bruce Fields
2007-05-06 8:53 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-29 18:33 UTC (permalink / raw)
To: git
We would need PerlIO fix for git-svn to handle symlinks on MacOS
properly on 'maint', which is still a known issue. With that
I'll do a v1.5.1.3.
In addition to a few more new features recently discussed, and
of course a lot of fixes that came in the last couple of days,
I've merged the "give them rope" conversion series to 'master'.
Hopefully we will have a handful user-manual updates from JBF
and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.
* The 'maint' branch has these fixes since the last announcement.
Adam Roben (1):
git-svn: Added 'find-rev' command
Johannes Schindelin (1):
import-tars: be nice to wrong directory modes
Josh Triplett (1):
Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation
Julian Phillips (1):
http.c: Fix problem with repeated calls of http_init
Junio C Hamano (3):
Do not barf on too long action description
Update .mailmap with "Michael"
Fix import-tars fix.
Michele Ballabio (1):
git shortlog documentation: add long options and fix a typo
Shawn O. Pearce (2):
Don't allow empty pathnames in fast-import
Catch empty pathnames in trees during fsck
* The 'master' branch has these since the last announcement
in addition to the above.
Josh Triplett (1):
Fall back to $EMAIL for missing GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
Junio C Hamano (7):
Add 'ident' conversion.
Add 'filter' attribute and external filter driver definition.
blame -s: suppress author name and time.
Split out mailmap handling out of shortlog
Apply mailmap in git-blame output.
Make macros to prevent double-inclusion in headers consistent.
Make sure test-genrandom and test-chmtime are builtas part of the main build.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-29 18:33 ` Junio C Hamano
@ 2007-04-30 4:15 ` J. Bruce Fields
2007-04-30 5:12 ` Junio C Hamano
2007-05-06 8:53 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: J. Bruce Fields @ 2007-04-30 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Apr 29, 2007 at 11:33:07AM -0700, Junio C Hamano wrote:
> Hopefully we will have a handful user-manual updates from JBF
> and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.
Sorry for the relative silence; I've had a busy couple of weeks keeping
me away from git, and a backlog of comments. I'll try to have a few
things ready tommorow (Monday) night, but nothing earth-shattering.--b.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-30 4:15 ` J. Bruce Fields
@ 2007-04-30 5:12 ` Junio C Hamano
2007-05-01 3:36 ` J. Bruce Fields
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-04-30 5:12 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, Apr 29, 2007 at 11:33:07AM -0700, Junio C Hamano wrote:
>> Hopefully we will have a handful user-manual updates from JBF
>> and git-gui 0.6.6 from Shawn and have v1.5.2-rc1 soon.
>
> Sorry for the relative silence; I've had a busy couple of weeks keeping
> me away from git, and a backlog of comments. I'll try to have a few
> things ready tommorow (Monday) night, but nothing earth-shattering.--b.
Thanks, and absolutely no reason to say sorry. This is a
collective volunteer effort and I believe your effort on the
user's manual so far has already made git much more approachable
to new people. It's greatly appreciated.
Besides, I made it sound as if -rc1 will be blocked, *waiting*
for these two updates, but it was a mistake; it doesn't have to
wait and documentation updates and polishes can happen anytime
before the final.
And contribution from others on the list, especially from people
with some git virginity still left, to review the user's manual
would be valuable.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-04-30 5:12 ` Junio C Hamano
@ 2007-05-01 3:36 ` J. Bruce Fields
0 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2007-05-01 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Apr 29, 2007 at 10:12:42PM -0700, Junio C Hamano wrote:
> Thanks, and absolutely no reason to say sorry. This is a
> collective volunteer effort and I believe your effort on the
> user's manual so far has already made git much more approachable
> to new people. It's greatly appreciated.
>
> Besides, I made it sound as if -rc1 will be blocked, *waiting*
> for these two updates, but it was a mistake; it doesn't have to
> wait and documentation updates and polishes can happen anytime
> before the final.
OK! I will get back to it soon....
> And contribution from others on the list, especially from people
> with some git virginity still left, to review the user's manual
> would be valuable.
Yep.--b.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-04-29 18:33 ` Junio C Hamano
2007-04-30 4:15 ` J. Bruce Fields
@ 2007-05-06 8:53 ` Junio C Hamano
2007-05-07 0:59 ` Jakub Narebski
2007-05-07 13:33 ` Frank Lichtenheld
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-05-06 8:53 UTC (permalink / raw)
To: git
Master is at v1.5.2-rc2; maint is probably ready to produce
v1.5.1.4, but not tonight.
Here are two draft release notes, followed by the usual "What's in"
summaries.
----------------------------------------------------------------
GIT v1.5.1.4 Release Notes (draft)
==========================
Fixes since v1.5.1.3
--------------------
* Bugfixes
- "git-http-fetch" did not work around a bug in libcurl
earlier than 7.16 (curl_multi_remove_handle() was broken).
- "git cvsserver" handles a file that was once removed and
then added again correctly.
- import-tars script (in contrib/) handles GNU tar archives
that contain pathnames longer than 100 bytes (long-link
extension) correctly.
- xdelta test program did not build correctly.
- gitweb sometimes tried incorrectly to apply function to
decode utf8 twice, resulting in corrupt output.
- "git blame -C" mishandled text at the end of a group of
lines.
- "git log/rev-list --boundary" did not produce output
correctly without --left-right option.
----------------------------------------------------------------
GIT v1.5.2 Release Notes (draft)
========================
Updates since v1.5.1
--------------------
* Plumbing level subproject support.
You can include a subdirectory that has an independent git
repository in your index and tree objects as a
"subproject". This plumbing (i.e. "core") level subproject
support explicitly excludes recursive behaviour.
The "subproject" entries in the index and trees are
incompatible with older versions of git. Experimenting with
the plumbing level support is encouraged, but be warned that
unless everybody in your project updates to this release or
later, using this feature would make your project
inaccessible by people with older versions of git.
* Plumbing level gitattributes support.
The gitattributes mechanism allows you to add 'attributes' to
paths in your project, and affect the way certain git
operations work. Currently you can influence if a path is
considered a binary or text (the former would be treated by
'git diff' not to produce textual output; the latter can go
through the line endings conversion process in repositories
with core.autocrlf set), expand and unexpand '$ident$' keyword
with blob object name, specify a custom 3-way merge driver,
and specify a custom diff driver. You can also apply
arbitrary filter to contents on check-in/check-out codepath
but this feature is an extremely sharp-edged razor and needs
to be handled with caution (do not use it unless you
understand the earlier mailing list discussion on keyward
expansion).
* The packfile format now optionally suports 64-bit index.
This release supports the "version 2" format of the .idx
file. This is automatically enabled when a huge packfile
needs more than 32-bit to express offsets of objects in the
pack
* New commands and options.
- "git bisect start" can optionally take a single bad commit and
zero or more good commits on the command line.
- "git shortlog" can optionally be told to wrap its output.
- "subtree" merge strategy allows another project to be merged in as
your subdirectory.
- "git format-patch" learned a new --subject-prefix=<string>
option, to override the built-in "[PATCH]".
- "git add -u" is a quick way to do the first stage of "git
commit -a" (i.e. update the index to match the working
tree); it obviously does not make a commit.
- "git clean" honors a new configuration, "clean.requireforce". When
set to true, this makes "git clean" a no-op, preventing you
from losing files by typing "git clean" when you meant to
say "make clean". You can still say "git clean -f" to
override this.
- "git log" family of commands learned --date={local,relative,default}
option. --date=relative is synonym to the --relative-date.
--date=local gives the timestamp in local timezone.
* Updated behavior of existing commands.
- When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
but $EMAIL is set, the latter is used as a substitute.
- "git diff --stat" shows size of preimage and postimage blobs
for binary contents. Earlier it only said "Bin".
- "git lost-found" shows stuff that are unreachable except
from reflogs.
- "git checkout branch^0" now detaches HEAD at the tip commit
on the named branch, instead of just switching to the
branch (use "git checkout branch" to switch to the branch,
as before).
- "git bisect next" can be used after giving only a bad commit
without giving a good one (this starts bisection half-way to
the root commit). We used to refuse to operate without a
good and a bad commit.
- "git push", when pushing into more than one repository, does
not stop at the first error.
- "git archive" does not insist you to give --format parameter
anymore; it defaults to "tar".
- "git cvsserver" can use backends other than sqlite.
- "gitview" (in contrib/ section) learned to better support
"git-annotate".
- "git diff $commit1:$path2 $commit2:$path2" can now report
mode changes between the two blobs.
- Local "git fetch" from a repository whose object store is
one of the alternates (e.g. fetching from the origin in a
repository created with "git clone -l -s") avoids
downloading objects unnecessary.
- "git blame" uses .mailmap to canonicalize the author name
just like "git shortlog" does.
* Builds
- git-p4import has never been installed; now there is an
installation option to do so.
- gitk and git-gui can be configured out.
- Generated documentation pages automatically get version
information from GIT_VERSION
- Parallel build with "make -j" descending into subdirectory
was fixed.
* Performance Tweaks
- Optimized "git-rev-list --bisect" (hence "git-bisect").
- Optimized "git-add $path" in a large directory, most of
whose contents are ignored.
- The recursive merge strategy updated a worktree file that
was changed identically in two branches, when one of them
renamed it. We do not do that when there is no rename, so
match that behaviour.
Fixes since v1.5.1
------------------
All of the fixes in v1.5.1 maintenance series are included in
this release, unless otherwise noted.
* Bugfixes
- Switching branches with "git checkout" refused to work when
a path changes from a file to a directory between the
current branch and the new branch, in order not to lose
possible local changes in the directory that is being turned
into a file with the switch. We now allow such a branch
switch after making sure that there is no locally modified
file nor un-ignored file in the directory. This has not
been backported to 1.5.1.x series, as it is rather an
intrusive change.
- Merging branches that have a file in one and a directory in
another at the same path used to get quite confused. We
handle such a case a bit more carefully, even though that is
still left as a conflict for the user to sort out. This
will not be backported to 1.5.1.x series, as it is rather an
intrusive change.
- git-fetch had trouble with a remote with insanely large number
of refs.
[[[jc: I'll probably copy&paste v1.5.1.X release notes here, or
refer readers to those separate documents. I haven't decided
which way I would go, but I am inclined to do the latter.]]]
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Small correction in reading of commit headers
Alexandre Julliard (1):
http-fetch: Disable use of curl multi support for libcurl < 7.16.
Arjen Laarhoven (1):
Document 'opendiff' value in config.txt and git-mergetool.txt
Bryan Larsen (2):
Allow PERL_PATH="/usr/bin/env perl"
posix compatibility for t4200
Carl Worth (1):
Mention version 1.5.1 in tutorial and user-manual
Daniel Barkalow (1):
Make xstrndup common
Frank Lichtenheld (1):
cvsserver: Handle re-added files correctly
Ismail Dönmez (1):
gitweb: use decode_utf8 directly
Jakub Narebski (1):
diff format documentation: describe raw combined diff format
James Bowes (1):
Documentation: fix typo in git-remote.txt
Johannes Schindelin (1):
Teach import-tars about GNU tar's @LongLink extension.
Junio C Hamano (4):
diff.c: fix "size cache" handling.
blame: Notice a wholesale incorporation of an existing file.
blame: -C -C -C
Add test for blame corner cases.
Karl Hasselström (2):
Fix markup in git-svn man page
Add --no-rebase option to git-svn dcommit
Linus Torvalds (1):
Fix --boundary output
Martin Koegler (1):
Fix compilation of test-delta
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Handle return code of parse_commit in revision machinery
Dana L. How (1):
Create pack-write.c for common pack writing code
Jonas Fonseca (1):
git-tag(1): -v option is a subcommand; fix code block
Junio C Hamano (2):
blame: use .mailmap unconditionally
GIT v1.5.2-rc2
Shawn O. Pearce (3):
Reuse fixup_pack_header_footer in index-pack
Don't use seq in tests, not everyone has it
Improve request-pull to handle non-rebased branches
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-04-09 8:17 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-09 8:17 UTC (permalink / raw)
To: git
Maybe will do 1.5.1.1 on Wednesday with the accumulated fixes on
'maint'.
The 'master' has a few topics merged from 'next':
- Christian Couder's "git bisect" improvements.
- Fernando J Perada's parallel make fix.
- Andy Parkins's "git diff --stat" for binary files.
- Shawn Pearce's "git lost-found" that ignores reflog.
- Switching between two branches that have D/F conflicts.
- "git merge -s subtree".
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Arjen Laarhoven (4):
usermanual.txt: some capitalization nits
t3200-branch.sh: small language nit
t5300-pack-object.sh: portability issue using /usr/bin/stat
Makefile: iconv() on Darwin has the old interface
Brian Gernhardt (2):
Document --left-right option to rev-list.
Distinguish branches by more than case in tests.
Dana How (1):
Fix lseek(2) calls with args 2 and 3 swapped
Eric Wong (3):
git-svn: bail out on incorrect command-line options
git-svn: dcommit/rebase confused by patches with git-svn-id: lines
git-svn: fix log command to avoid infinite loop on long commit messages
Frank Lichtenheld (6):
cvsimport: sync usage lines with existing options
cvsimport: Improve documentation of CVSROOT and CVS module determination
cvsimport: Improve usage error reporting
cvsimport: Reorder options in documentation for better understanding
cvsimport: Improve formating consistency
cvsserver: small corrections to asciidoc documentation
Geert Bosch (1):
Fix renaming branch without config file
Jakub Narebski (1):
gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
Junio C Hamano (3):
Fix dependency of common-cmds.h
Documentation: tighten dependency for git.{html,txt}
Add Documentation/cmd-list.made to .gitignore
Lars Hjemli (2):
rename_ref(): only print a warning when config-file update fails
Make builtin-branch.c handle the git config file
René Scharfe (1):
Revert "builtin-archive: use RUN_SETUP"
Shawn O. Pearce (1):
Honor -p<n> when applying git diffs
Ville Skyttä (1):
DESTDIR support for git/contrib/emacs
YOSHIFUJI Hideaki (1):
Avoid composing too long "References" header.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix passing of TCLTK_PATH to git-gui
Andy Parkins (1):
Show binary file size change in diff --stat
Christian Couder (2):
Bisect: teach "bisect start" to optionally use one bad and many good revs.
Documentation: bisect: "start" accepts one bad and many good commits
Fernando J. Pereda (1):
Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.
Junio C Hamano (21):
git-fetch: add --quiet
checkout: allow detaching to HEAD even when switching to the tip of a branch
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
git-read-tree --index-output=<file>
add_cache_entry(): removal of file foo does not conflict with foo/bar
unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
unpack-trees: get rid of *indpos parameter.
Fix read-tree --prefix=dir/.
Fix twoway_merge that passed d/f conflict marker to merged_entry().
Fix switching to a branch with D/F when current branch has file D.
Fix bogus error message from merge-recursive error path
Propagate cache error internal to refresh_cache() via parameter.
Rename internal function "add_file_to_cache" in builtin-update-index.c
Rename static variable write_index to update_index in builtin-apply.c
Rename add_file_to_index() to add_file_to_cache()
git-bisect: modernization
t6030: add a bit more tests to git-bisect
git-bisect: allow bisecting with only one bad commit.
git-push reports the URL after failing.
git-push to multiple locations does not stop at the first failure
A new merge stragety 'subtree'.
Nicolas Pitre (1):
clean up and optimize nth_packed_object_sha1() usage
Shawn O. Pearce (1):
Fix lost-found to show commits only referenced by reflogs
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-03-31 9:34 Junio C Hamano
2007-03-31 11:54 ` Alex Riesen
2007-04-05 6:44 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-31 9:34 UTC (permalink / raw)
To: git
As you can see, there are a few more fixes on the 'maint' branch
since 1.5.0.6; I might do 1.5.0.7 just for the sake of it, but I
am fairly determined to tag 1.5.1 on Apr 4th in a shape that is
"no worse" than 1.5.0, so it might not be strictly necessary.
If you can remind me of patches that are "must have"s for 1.5.1
that I've missed, that would be very nice. We've broken "git
am" and "git rebase" (without --merge) on 'master' branch for
people who has i18n contents after 1.5.0 but they should be
fixed now.
Please, remember that the key word for this weekend is "make
1.5.1 NO WORSE than 1.5.0". IOW, the focus is on obvious
regression fixes.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Gerrit Pape (2):
Documentation/git-svnimport.txt: fix typo.
Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.
H. Peter Anvin (1):
git-upload-pack: make sure we close unused pipe ends
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (1):
Reimplement emailing part of hooks--update in contrib/hooks/post-receive-email
Christian Couder (1):
Bisect: Improve error message in "bisect_next_check".
Don Zickus (1):
git-mailinfo fixes for patch munging
Eric Wong (1):
git-svn: avoid respewing similar error messages for missing paths
Francis Daly (1):
git-quiltimport /bin/sh-ism fix
Jakub Narebski (1):
gitweb: Support comparing blobs (files) with different names
Julian Phillips (1):
contrib/workdir: add a simple script to create a working directory
Junio C Hamano (2):
Update draft release notes for 1.5.1
Do not bother documenting fetch--tool
Theodore Ts'o (12):
Fix minor formatting issue in man page for git-mergetool
mergetool: Replace use of "echo -n" with printf(1) to be more portable
mergetool: Don't error out in the merge case where the local file is deleted
mergetool: portability fix: don't assume true is in /bin
mergetool: portability fix: don't use reserved word function
mergetool: factor out common code
mergetool: Remove spurious error message if merge.tool config option not set
mergetool: Fix abort command when resolving symlinks and deleted files
mergetool: Add support for Apple Mac OS X's opendiff command
mergetool: Make git-rm quiet when resolving a deleted file conflict
mergetool: Clean up description of files and prompts for merge resolutions
Rename warn() to warning() to fix symbol conflicts on BSD and Mac OS
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-03-31 9:34 Junio C Hamano
@ 2007-03-31 11:54 ` Alex Riesen
2007-04-05 6:44 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Alex Riesen @ 2007-03-31 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano, Sat, Mar 31, 2007 11:34:14 +0200:
>
> If you can remind me of patches that are "must have"s for 1.5.1
> that I've missed, that would be very nice. We've broken "git
> am" and "git rebase" (without --merge) on 'master' branch for
> people who has i18n contents after 1.5.0 but they should be
> fixed now.
We still have absolutely broken merge-recursive WRT rename/rename
conflicts in intermediate trees.
> Please, remember that the key word for this weekend is "make
> 1.5.1 NO WORSE than 1.5.0". IOW, the focus is on obvious
> regression fixes.
It is "no worse", but doesn't "pretty bad" count?
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-03-31 9:34 Junio C Hamano
2007-03-31 11:54 ` Alex Riesen
@ 2007-04-05 6:44 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-04-05 6:44 UTC (permalink / raw)
To: git
So here is the status for tonight.
* There is no biggie in 'maint' yet.
* On 'master', as I promised, the following topics are merged:
- An option to install p4import, and make it part of the RPM
binary package suite.
- An option to exclude git-gui and gitk.
- Build tweak to include GIT_VERSION string in the documentation.
- Optimize "add single-path" in a huge directory whose
contents are mostly ignored.
- Optimize "rev-list --bisect".
- A handful gitweb, git-svn and git-blame.el cleanups.
In addition, a few patches are also in:
- "diff --stat" to show bytesize changes for binary files.
- "lost-found" to ignore objects only reachable from the reflog.
- "patch -p<n>" is honored even for "diff --git" patches.
- A handful internal clean-ups.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.1
Brian Gernhardt (1):
Fix t4200-rerere for white-space from "wc -l"
Gerrit Pape (1):
rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
Junio C Hamano (1):
rerere: make sorting really stable.
* The 'master' branch has these since v1.5.1 in addition to the above.
Andy Parkins (1):
Show binary file size change in diff --stat
Brian Gernhardt (1):
Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec
Eric Wong (1):
git-svn: bail out on incorrect command-line options
Eygene Ryabinkin (7):
Add the WITH_P4IMPORT knob to the Makefile.
Added git-p4 package to the list of git RPMs.
Added correct Python path to the RPM specfile.
NO_TCLTK
Add --with-tcltk and --without-tcltk to configure.
Rewrite Tcl/Tk interpreter path for the GUI tools.
Eliminate checks of user-specified Tcl/Tk interpreter.
Frank Lichtenheld (2):
Documentation: Replace @@GIT_VERSION@@ in documentation
Documentation: Add version information to man pages
Jakub Narebski (2):
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (3)
gitweb: Quote hash keys, and do not use barewords keys
Junio C Hamano (14):
t6002: minor spelling fix.
git-rev-list: add --bisect-vars option.
git-rev-list --bisect: optimization
t6004: add a bit more path optimization test.
rev-list --bisect: Fix "halfway" optimization.
make the previous optimization work also on path-limited rev-list --bisect
Documentation: unbreak user-manual.
Optional Tck/Tk: ignore generated files.
RPM spec: include git-p4 in the list of all packages.
Fix bogus error message from merge-recursive error path
Propagate cache error internal to refresh_cache() via parameter.
Rename internal function "add_file_to_cache" in builtin-update-index.c
Rename static variable write_index to update_index in builtin-apply.c
Rename add_file_to_index() to add_file_to_cache()
Linus Torvalds (1):
Optimize directory listing with pathspec limiter.
Nicolas Pitre (1):
clean up and optimize nth_packed_object_sha1() usage
Shawn O. Pearce (2):
Fix lost-found to show commits only referenced by reflogs
Honor -p<n> when applying git diffs
Xavier Maillard (2):
git-blame.el: separate git-blame-mode to ease maintenance
git-blame.el: pick a set of random colors for each git-blame turn
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-02-20 7:32 Junio C Hamano
2007-02-23 8:33 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-20 7:32 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since v1.5.0.1
Christian Schlotter (1):
git-clone: Sync documentation to usage note.
Jason Riedy (2):
Add a compat/strtoumax.c for Solaris 8.
Obey NO_C99_FORMAT in fast-import.c.
* The 'master' branch has these since the last announcement, in
addition to the above.
Andy Parkins (1):
Have git-cvsserver call hooks/update before really altering the ref
Fredrik Kuivinen (2):
Read the config in rev-list
Documentation/i18n.txt: it is i18n.commitencoding not core.commitencoding
Johannes Schindelin (2):
name-rev: introduce the --refs=<pattern> option
diff --check: use colour
Junio C Hamano (9):
Make gitk work reasonably well on Cygwin.
gitk: Use show-ref instead of ls-remote
remotes.not-origin.tagopt
pretend-sha1: grave bugfix.
git-merge: minor fix for no_trivial_merge_strategies.
Do not take mode bits from index after type change.
Update draft release notes for 1.5.0.1
Update draft release notes for 1.5.1
GIT 1.5.0.1
Mark Levedahl (3):
gitk - remove trailing whitespace from a few lines.
Make gitk save and restore the user set window position.
Make gitk save and restore window pane position on Linux and Cygwin.
Paul Mackerras (1):
Change git repo-config to git config
Shawn O. Pearce (2):
Attempt to improve git-rebase lead-in description.
Convert update-index references in docs to add.
Theodore Ts'o (1):
Teach git-remote to update existing remotes by fetching from them
Tommi Kyntola (1):
git-blame: prevent argument parsing segfault
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-02-20 7:32 Junio C Hamano
@ 2007-02-23 8:33 ` Junio C Hamano
2007-03-04 10:32 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23 8:33 UTC (permalink / raw)
To: git
On the 'maint' front, there aren't that many 'grave fixes'
anymore, which is somewhat (happily) surprising after a big
release like 1.5.0. Shawn has updated git-gui to 0.6.1.
I'll perhaps do 1.5.0.2 next week.
In 'master', I pushed out autoCRLF and git-apply fixes. These
are changes people can easily notice breakage and would benefit
from wider exposure. Hopefully we can have simple path based
text/binary attribute on top of them -- I am hoping it to come
from people who actually benefit from autoCRLF ;-).
* The 'maint' branch has these fixes since the last announcement.
Fredrik Kuivinen (1):
Fix 'git commit -a' in a newly initialized repository
Jason Riedy (1):
Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.
Johannes Schindelin (1):
git-diff: fix combined diff
Martin Koegler (1):
git-gui: Create new branches from a tag.
Michael Loeffler (1):
Use gunzip -c over gzcat in import-tars example.
Shawn O. Pearce (16):
git-gui: Refactor 'exec git subcmd' idiom.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Permit merging tags into the current branch.
git-gui: More consistently display the application name.
git-gui: Print version on the console.
git-gui: Prefer version file over git-describe.
git-gui: Expose the browser as a subcommand.
git-gui: Correct crash when saving options in blame mode.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Display all authors of git-gui.
git-gui: Change summary of git-gui.
git-gui: Include browser in our usage message.
git-gui: Remove TODO list.
git-gui: Don't crash in citool mode on initial commit.
Document the new core.bare configuration option.
Include git-gui credits file in dist.
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
disable t4016-diff-quote.sh on some filesystems
Fredrik Kuivinen (2):
New autoconf test for iconv
Fix 'git commit -a' in a newly initialized repository
Jason Riedy (1):
Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.
Johannes Schindelin (5):
apply: fix memory leak in prefix_one()
name-rev: avoid "^0" when unneeded
git grep: use pager
Teach diff -B about colours
git-diff: fix combined diff
Junio C Hamano (16):
t0020: add test for auto-crlf
Teach 'git apply' to look at $GIT_DIR/config
Teach core.autocrlf to 'git apply'
Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository
git-apply: do not lose cwd when run from a subdirectory.
git-apply: require -p<n> when working in a subdirectory.
Link 1.5.0.1 documentation from the main page.
Add prefixcmp()
Mechanical conversion to use prefixcmp()
prefixcmp(): fix-up mechanical conversion.
prefixcmp(): fix-up leftover strncmp().
t4119: add test for traditional patch and different p_value
Fix botched "leak fix"
git-apply: notice "diff --git" patch again
git-apply: guess correct -p<n> value for non-git patches.
t4119: test autocomputing -p<n> for traditional diff input.
Linus Torvalds (2):
Lazy man's auto-CRLF
Make AutoCRLF ternary variable.
Martin Koegler (1):
git-gui: Create new branches from a tag.
Martin Waitz (1):
Support for large files on 32bit systems.
Michael Loeffler (1):
Use gunzip -c over gzcat in import-tars example.
Pavel Roskin (1):
git-remote: support remotes with a dot in the name
Shawn O. Pearce (16):
git-gui: Refactor 'exec git subcmd' idiom.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Permit merging tags into the current branch.
git-gui: More consistently display the application name.
git-gui: Print version on the console.
git-gui: Prefer version file over git-describe.
git-gui: Expose the browser as a subcommand.
git-gui: Correct crash when saving options in blame mode.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Display all authors of git-gui.
git-gui: Change summary of git-gui.
git-gui: Include browser in our usage message.
git-gui: Remove TODO list.
git-gui: Don't crash in citool mode on initial commit.
Document the new core.bare configuration option.
Include git-gui credits file in dist.
Simon 'corecode' Schubert (1):
Allow passing of an alternative CVSROOT via -d.
Theodore Ts'o (2):
Add config_boolean() method to the Git perl module
Allow git-remote to update named groups of remotes
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-02-23 8:33 ` Junio C Hamano
@ 2007-03-04 10:32 ` Junio C Hamano
2007-03-13 8:49 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-03-04 10:32 UTC (permalink / raw)
To: git
I'll do another maintenance release 1.5.0.3 soonish to flush
accumulated fixes on 'maint' branch.
On the 'master' front, we have
* a largish git-svn updates.
* a handful git diff improvements.
* a beginning of CRLF mangling.
* improved behaviour of git-apply run in subdirectories.
* /etc/gitconfig
Soon we will also have these from 'next'. I think it will be
time to do v1.5.1 after they are in:
* "fake symlink" work for MinGW port
* built-in revert/cherry-pick
* "git diff" that compares stdin and /dev/null
* make "git fetch" quieter when noninteractive.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.0.2.
Alexandre Julliard (1):
git.el: Set the default commit coding system from the repository config.
Aneesh Kumar K.V (1):
blameview: Fix the browse behavior in blameview
Christian Schlotter (1):
Documentation: Correct minor typo in git-add documentation.
Eygene Ryabinkin (2):
http-push.c::lock_remote(): validate all remote refs.
Another memory overrun in http-push.c
Gerrit Pape (2):
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
Fix quoting in update hook template
Jim Meyering (1):
diff --cc: integer overflow given a 2GB-or-larger file
Johannes Schindelin (3):
fetch.o depends on the headers, too.
builtin-archive: use RUN_SETUP
Document the config variable format.suffix
Junio C Hamano (4):
git-apply: do not fix whitespaces on context lines.
Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url
Start preparing Release Notes for 1.5.0.3
git-merge: fail correctly when we cannot fast forward.
Linus Torvalds (2):
mailinfo: do not get confused with logical lines that are too long.
git-show: Reject native ref
Matthias Kestenholz (1):
Fix git-gc usage note
Michael Coleman (2):
Fix minor typos/grammar in user-manual.txt
builtin-fmt-merge-msg: fix bugs in --file option
Michael Poole (1):
Correct ordering in git-cvsimport's option documentation
Paolo Bonzini (1):
git-archimport: support empty summaries, put summary on a single line.
Ramsay Allan Jones (5):
Fix a "label defined but unreferenced" warning.
Fix an "implicit function definition" warning.
Fix some "comparison is always true/false" warnings.
Fix a "pointer type missmatch" warning.
Unset NO_C99_FORMAT on Cygwin.
Sergey Vlasov (3):
Documentation/build-docdep.perl: Fix dependencies for included asciidoc files
Documentation/git-quiltimport.txt: Fix labeled list formatting
Documentation/git-send-email.txt: Fix labeled list formatting
Shawn O. Pearce (1):
index-pack: Loop over pread until data loading is complete.
Theodore Ts'o (1):
Fix git-show man page formatting in the EXAMPLES section
Uwe Kleine-König (1):
Include config.mak in doc/Makefile
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (3):
cvsserver: Remove trailing "\n" from commithash in checkin function
cvsserver: Make always-binary mode a config file option
Sample update hook: typofix and modernization to use "git log"
Aneesh Kumar K.V (1):
Documentation: document remote.<name>.tagopt
Eric Wong (118):
git-svn: move authentication prompts into their own namespace
git-svn: cleanup: move process_rm around
git-svn: cleanup: put SVN workarounds into their own namespace
git-svn: cleanup: avoid re-use()ing Git.pm in sub-packages
git-svn: add Git::SVN module (to avoid global variables)
git-svn: convert 'init' to use Git::SVN
git-svn: convert multi-init over to using Git::SVN
git-svn: make multi-init capable of reusing the Ra connection
git-svn: add a test for show-ignore
git-svn: convert show-ignore over to Git::SVN
git-svn: moved the 'log' command into its own namespace
git-svn: port the 'rebuild' command to use Git::SVN objects
git-svn: do not let Git.pm warn if we prematurely close pipes
git-svn: convert the 'commit-diff' command to Git::SVN
git-svn: get rid of Memoize for now...
git-svn: fetch/multi-fetch converted over to Git::SVN module
git-svn: switch dcommit to using Git::SVN code
git-svn: convert 'set-tree' command to use Git::SVN
git-svn: remove graft-branches command
git-svn: add support for metadata in .git/config
git-svn: fix a regression in dcommit that caused empty log messages
git-svn: reuse open SVN::Ra connections by URL
git-svn: enable --minimize to simplify the config and connections
git-svn: fix --follow-parent to work with Git::SVN
git-svn: --follow-parent works with svn-remotes multiple branches
git-svn: disallow ambigious local refspecs
git-svn: allow --follow-parent on deleted directories
git-svn: get rid of additional fetch-arguments
git-svn: allow 'init' to work outside of tests
git-svn: better error reporting if --follow-parent fails
git-svn: 'init' attempts to connect to the repository root if possible
git-svn: --follow-parent now works on sub-directories of larger branches
git-svn: track writes writes to the index in fetch
git-svn: add an odd test case that seems to cause segfaults over HTTP
git-svn: avoid tracking change-less revisions
git-svn: correctly track revisions made to deleted branches
git-svn: fix segfaults from accessing svn_log_changed_path_t
git-svn: fix committing to subdirectories, add tests
git-svn: avoid an extra svn_ra connection during commits
git-svn: simplify usage of the SVN::Git::Editor interface
git-svn: cleanup remove unused function
git-svn: allow multi-fetch to fetch things chronologically
git-svn: correctly track diff-less copies with do_switch
git-svn: correctly handle do_{switch,update} in deep directories
git-svn: stop using path names as refnames with --follow-parent
git-svn: cleanup: move editor-specific variables into the editor namespace
git-svn: just use Digest::MD5 instead of requiring it
git-svn: reinstate the default SVN error handler after using get_log
git-svn: don't rely on do_switch + reparenting with svn(+ssh)://
git-svn: fetch tracks initial change with --follow-parent
git-svn: remove the 'rebuild' command and make the functionality automatic
git-svn: fix several fetch bugs related to repeated invocations
git-svn: reinstate --no-metadata, add --svn-remote=, variable cleanups
git-svn: gracefully handle --follow-parent failures
git-svn: make (multi-)fetch safer but slower
git-svn: avoid a huge memory spike with high-numbered revisions
git-svn: re-enable repacking flags
git-svn: do our best to ensure that our ref and rev_db are consistent
git-svn: avoid redundant get_log calls between invocations
git-svn: use sys* IO functions for reading rev_db
git-svn: don't write to the config file from --follow-parent
git-svn: save paths to tags/branches with for future reuse
git-svn: migrations default to [svn-remote "git-svn"]
git-svn: get rid of revisions_eq check for --follow-parent
git-svn: avoid extra get_log calls when refspecs are added for fetching
git-svn: just name the default svn-remote "svn" instead of "git-svn"
git-svn: prepare multi-init for wildcard support
git-svn: reintroduce using a single get_log() to fetch
git-svn: run get_log() on a sub-directory if possible
git-svn: implement auto-discovery of branches/tags
git-svn: --follow-parent tracks multi-parent paths
git-svn: remove check_path calls before calling do_update
git-svn: remove some noisy debugging messages
git-svn: enable follow-parent functionality by default
git-svn: fix buggy regular expression usage in several places
git-svn: correctly handle the -q flag in SVN::Git::Fetcher
git-svn: correctly handle globs with a right-hand-side path component
git-svn: remove optimized commit stuff for set-tree
git-svn: add support for SVN::Mirror/svk using revprops for metadata
git-svn: add support for per-[svn-remote "..."] options
git-svn: use private $GIT_DIR/svn/config file more
git-svn: extra safety for noMetadata and useSvmProps users
git-svn: use separate, per-repository .rev_db files
git-svn: write the highest maxRex out for branches and tags
git-svn: handle multi-init without --trunk, UseSvmProps fixes
git-svn: make dcommit usable for glob users
git-svn: include merges when calling rev-list for decommit
git-svn: usability fixes for the 'git svn log' command
t910*: s/repo-config/config/g; poke around possible race conditions
git-svn: hopefully make 'fetch' more user-friendly
git-svn: allow 'init' to act as multi-init
git-svn: brown paper bag fixes
git-svn: simplify the (multi-)init methods of fetching
git-svn: allow --log-window-size to be specified, default to 100
git-svn: remember to check for clean indices on globbed refs, too
git-svn: error checking for invalid [svn-remote "..."] sections
git-svn: allow dcommit for those who only fetch from SVM with useSvmProps
git-svn: documentation updates for new functionality
git-svn: add support for --stat in the log command
git-svn: checkout files on new fetches
git-svn: add a 'rebase' command
git-svn: fix some issues for people migrating from older versions
git-svn: hide the private git-svn 'config' file as '.metadata'
git-svn: add 'clone' command, an alias for init + fetch
git-svn: allow overriding of the SVN repo root in metadata
git-svn: add support for using svnsync properties
git-svn: fix useSvmProps, hopefully for the last time
git-svn: add test for useSvnsyncProps
git-svn: documentation updates
git-svn: allow metadata options to be specified with 'init' and 'clone'
git-svn: give show-ignore HEAD smarts, like dcommit and log
git-svn: ensure we're at the top-level and can access $GIT_DIR
git-svn: fix clone when a target directory has been specified
git-svn: fix reconnections to different paths of svn:// repositories
git-svn: fix some potential bugs with --follow-parent
Add test-chmtime: a utility to change mtime on files
Update tests to use test-chmtime
git-svn: fix show-ignore when not connected to the repository root
Johannes Schindelin (18):
rev-list --max-age, --max-count: support --boundary
config: read system-wide defaults from /etc/gitconfig
apply: make --verbose a little more useful
Teach git-diff-files the new option `--no-index`
pretty-formats: add 'format:<string>'
Make tests independent of global config files
Add git-bundle: move objects and references by archive
git-bundle: assorted fixes
git-bundle: avoid fork() in verify_bundle()
git-bundle: fix 'create --all'
git-bundle: record commit summary in the prerequisite data
object name: introduce ':/<oneline prefix>' notation
Fix typo: do not show name1 when name2 fails
diff --no-index: also imitate the exit status of diff(1)
Actually make print_wrapped_text() useful
show_date(): rename the "relative" parameter to "mode"
diff: make more cases implicit --no-index
print_wrapped_text: fix output for negative indent
Julian Phillips (2):
git-branch: improve abbreviation of sha1s in verbose mode
git-branch: document new --no-abbrev option
Junio C Hamano (13):
git-status: do not be totally useless in a read-only repository.
update-index: do not die too early in a read-only repository.
run_diff_{files,index}(): update calling convention.
.mailmap maintenance after pulling from git-svn
bundle: reword missing prerequisite error message
diff --cached: give more sensible error message when HEAD is yet to be created.
Documentation: link in 1.5.0.2 material to the top documentation page.
Make 'cvs ci' lockless in git-cvsserver by using git-update-ref
index_fd(): use enum object_type instead of type name string.
index_fd(): pass optional path parameter as hint for blob conversion
index_fd(): convert blob only if it is a regular file.
Add recent changes to draft 1.5.1 release notes.
diff-ni: allow running from a subdirectory.
Michael Coleman (2):
git-send-email: abort/usage on bad option
fix various doc typos
Nicolas Pitre (7):
sha1_file.c: cleanup hdr usage
sha1_file.c: cleanup "offset" usage
sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
formalize typename(), and add its reverse type_from_string()
convert object type handling from a string to a number
get rid of lookup_object_type()
make sure enum object_type is signed
Sam Vilain (3):
git-svn: make test for SVK mirror path import
git-svn: don't consider SVN URL usernames significant when comparing
git-svn: document --username
Sergey Vlasov (1):
Documentation/git-svn.txt: Fix formatting errors
Shawn O. Pearce (1):
Cleanup check_valid in commit-tree.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-03-04 10:32 ` Junio C Hamano
@ 2007-03-13 8:49 ` Junio C Hamano
2007-03-13 9:26 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-13 8:49 UTC (permalink / raw)
To: git
Perhaps it is time for 1.5.0.4 this Wednesday (my time) from
'maint'.
On the 'master' front, Johannes and Matthias cleaned up the
git-bundle and made it (hopefully) usable shape. Also git-diff
got even nicer when used outside the context of git, again
thanks to Johannes. I think we are nearing 1.5.1-rc1, which
I'll talk about in "What's cooking".
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Alexandre Julliard (2):
git.el: Avoid appending a signoff line that is already present.
git.el: Retrieve commit log information from .dotest directory.
Avi Kivity (1):
git-send-email: Document configuration options
Brian Gernhardt (1):
Fix diff-options references in git-diff and git-format-patch
J. Bruce Fields (13):
Documentation: mention module option to git-cvsimport
user-manual: reset to ORIG_HEAD not HEAD to undo merge
user-manual: ensure generated manual references stylesheet
user-manual: insert earlier of mention content-addressable architecture
user-manual: how to replace commits older than most recent
user-manual: more detailed merge discussion
glossary: fix overoptimistic automatic linking of defined terms
user-manual: fix inconsistent example
user-manual: fix inconsistent use of pull and merge
user-manual: fix missing colon in git-show example
user-manual: fix rendering of history diagrams
user-manual: install user manual stylesheet with other web documents
git-merge: warn when -m provided on a fast forward
Jeff King (2):
Documentation: s/seperator/separator/
fast-import: grow tree storage more aggressively
Johannes Schindelin (2):
Begin SubmittingPatches with a check list
make t8001 work on Mac OS X again
Junio C Hamano (2):
GIT 1.5.0.3
git-commit: cd to top before showing the final stat
Matthias Kestenholz (1):
Adjust reflog filemode in shared repository
Matthias Lederhofer (1):
setup_git_directory_gently: fix off-by-one error
Shawn O. Pearce (13):
git-gui: Relocate the menu/transport menu code.
git-gui: Add Reset to the Branch menu.
git-gui: Don't create empty (same tree as parent) commits.
git-gui: Remove unnecessary /dev/null redirection.
fast-import: Avoid infinite loop after reset
fast-import: Fail if a non-existant commit is used for merge
git-gui: Make 'make' quieter by default
Catch write_ref_sha1 failure in receive-pack
git-gui: Allow committing empty merges
git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
git-gui: Revert "git-gui: Display all authors of git-gui."
git-gui: Allow 'git gui version' outside of a repository
Don't package the git-gui credits file anymore
Theodore Ts'o (1):
Add definition of <commit-ish> to the main git man page.
Yasushi SHOJI (1):
glossary: Add definitions for dangling and unreachable objects
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (4):
git-gui: Support of "make -s" in: do not output anything of the build itself
More build output cleaning up
Support of "make -s": do not output anything of the build itself
Allow "make -w" generate its usual output
Avi Kivity (1):
git-send-email: configurable bcc and chain-reply-to
Frank Lichtenheld (1):
cvsserver: Use Merged response instead of Update-existing for merged files
Jakub Narebski (1):
gitweb: Don't escape attributes in CGI.pm HTML methods
Jeff King (1):
New fast-import test case for valid tree sorting
Jim Meyering (1):
I like the idea of the new ':/<oneline prefix>' notation, and gave it
Johannes Schindelin (15):
fetch & clone: do not output progress when not on a tty
Fixup no-progress for fetch & clone
Make git-revert & git-cherry-pick a builtin
diff: support reading a file from stdin via "-"
diff --no-index: support /dev/null as filename
Get rid of the dependency to GNU diff in the tests
cherry-pick: Suggest a better method to retain authorship
format-patch: add --inline option and make --attach a true attachment
bundle: fix wrong check of read_header()'s return value & add tests
git-bundle: avoid packing objects which are in the prerequisites
git-bundle: Make thin packs
git-bundle: handle thin packs in subcommand "unbundle"
git-bundle: die if a given ref is not included in bundle
git-bundle: prevent overwriting existing bundles
git-bundle: only die if pack would be empty, warn if ref is skipped
Johannes Sixt (3):
Add core.symlinks to mark filesystems that do not support symbolic links.
Handle core.symlinks=false case in merge-recursive.
Tell multi-parent diff about core.symlinks.
Junio C Hamano (14):
diff-ni: fix the diff with standard input
format-patch --attach: not folding some long headers.
Post 1.5.0.3 cleanup
fsck: fix broken loose object check.
unpack_sha1_file(): detect corrupt loose object files.
fsck: exit with non-zero status upon errors
git-bundle: fix pack generation.
revision walker: Fix --boundary when limited
revision traversal: retire BOUNDARY_SHOW
git-bundle: various fixups
revision traversal: SHOWN means shown
git-bundle: make verify a bit more chatty.
revision --boundary: fix stupid typo
revision --boundary: fix uncounted case.
Li Yang (1):
gitweb: Change to use explicitly function call cgi->escapHTML()
Linus Torvalds (1):
Re-fix get_sha1_oneline()
Paolo Bonzini (3):
git-config: document --rename-section, provide --remove-section
git-archimport: allow remapping branch names
git-commit: add a --interactive option
Santi Béjar (2):
t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch
t/t5515-fetch-merge-logic.sh: Add two more tests
Shawn O. Pearce (31):
cherry-pick: Bug fix 'cherry picked from' message.
Make 'make' quieter while building git
Make 'make' quiet by default
Display the null SHA-1 as the base for an OBJ_OFS_DELTA.
Fix mmap leak caused by reading bad indexes.
Don't build external_grep if its not used
General const correctness fixes
Use uint32_t for all packed object counts.
Use uint32_t for pack-objects counters.
Use off_t when we really mean a file offset.
Use off_t in pack-objects/fast-import when we mean an offset
Cast 64 bit off_t to 32 bit size_t
Preallocate memory earlier in fast-import
Move post-update hook to after all other activity
Don't run post-update hook unless a ref changed
Refactor run_update_hook to be more useful
Refactor handling of error_string in receive-pack
Teach receive-pack to run pre-receive/post-receive hooks
Use atomic updates to the fast-import mark file
Allow fast-import frontends to reload the marks table
Switch to run_command_v_opt in revert
Remove unused run_command variants
Start defining a more sophisticated run_command
Split run_command into two halves (start/finish)
Teach run_command how to setup a stdin pipe
Refactor run_command error handling in receive-pack
Split back out update_hook handling in receive-pack
Change {pre,post}-receive hooks to use stdin
Remove unnecessary casts from fast-import
Simplify closing two fds at once in run-command.c
Fix t5510-fetch's use of sed
Xavier Maillard (1):
contrib/emacs: Use non-interactive function to byte-compile files
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-03-13 8:49 ` Junio C Hamano
@ 2007-03-13 9:26 ` Junio C Hamano
2007-03-22 17:08 ` Steven Grimm
2007-03-25 8:32 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-13 9:26 UTC (permalink / raw)
To: git
Junio C Hamano <junkio@cox.net> writes:
> On the 'master' front, Johannes and Matthias cleaned up the
> git-bundle and made it (hopefully) usable shape.
Sorry, but I meant Mark Levedahl here.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-03-13 8:49 ` Junio C Hamano
2007-03-13 9:26 ` Junio C Hamano
@ 2007-03-22 17:08 ` Steven Grimm
2007-03-22 21:30 ` Junio C Hamano
2007-03-25 8:32 ` Junio C Hamano
2 siblings, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2007-03-22 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Will you be applying your patch for the "checkout fails if something is
a file in one branch and a directory in another" problem? I realize it's
not a complete solution, but it's at least a significant improvement
over the current behavior, and I don't imagine it breaks anything else.
I can resend my test case if you like.
-Steve
Junio C Hamano wrote:
> Perhaps it is time for 1.5.0.4 this Wednesday (my time) from
> 'maint'.
>
> On the 'master' front, Johannes and Matthias cleaned up the
> git-bundle and made it (hopefully) usable shape. Also git-diff
> got even nicer when used outside the context of git, again
> thanks to Johannes. I think we are nearing 1.5.1-rc1, which
> I'll talk about in "What's cooking".
>
> ----------------------------------------------------------------
>
> * The 'maint' branch has these fixes since the last announcement.
>
> Alexandre Julliard (2):
> git.el: Avoid appending a signoff line that is already present.
> git.el: Retrieve commit log information from .dotest directory.
>
> Avi Kivity (1):
> git-send-email: Document configuration options
>
> Brian Gernhardt (1):
> Fix diff-options references in git-diff and git-format-patch
>
> J. Bruce Fields (13):
> Documentation: mention module option to git-cvsimport
> user-manual: reset to ORIG_HEAD not HEAD to undo merge
> user-manual: ensure generated manual references stylesheet
> user-manual: insert earlier of mention content-addressable architecture
> user-manual: how to replace commits older than most recent
> user-manual: more detailed merge discussion
> glossary: fix overoptimistic automatic linking of defined terms
> user-manual: fix inconsistent example
> user-manual: fix inconsistent use of pull and merge
> user-manual: fix missing colon in git-show example
> user-manual: fix rendering of history diagrams
> user-manual: install user manual stylesheet with other web documents
> git-merge: warn when -m provided on a fast forward
>
> Jeff King (2):
> Documentation: s/seperator/separator/
> fast-import: grow tree storage more aggressively
>
> Johannes Schindelin (2):
> Begin SubmittingPatches with a check list
> make t8001 work on Mac OS X again
>
> Junio C Hamano (2):
> GIT 1.5.0.3
> git-commit: cd to top before showing the final stat
>
> Matthias Kestenholz (1):
> Adjust reflog filemode in shared repository
>
> Matthias Lederhofer (1):
> setup_git_directory_gently: fix off-by-one error
>
> Shawn O. Pearce (13):
> git-gui: Relocate the menu/transport menu code.
> git-gui: Add Reset to the Branch menu.
> git-gui: Don't create empty (same tree as parent) commits.
> git-gui: Remove unnecessary /dev/null redirection.
> fast-import: Avoid infinite loop after reset
> fast-import: Fail if a non-existant commit is used for merge
> git-gui: Make 'make' quieter by default
> Catch write_ref_sha1 failure in receive-pack
> git-gui: Allow committing empty merges
> git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
> git-gui: Revert "git-gui: Display all authors of git-gui."
> git-gui: Allow 'git gui version' outside of a repository
> Don't package the git-gui credits file anymore
>
> Theodore Ts'o (1):
> Add definition of <commit-ish> to the main git man page.
>
> Yasushi SHOJI (1):
> glossary: Add definitions for dangling and unreachable objects
>
>
> * The 'master' branch has these since the last announcement
> in addition to the above.
>
> Alex Riesen (4):
> git-gui: Support of "make -s" in: do not output anything of the build itself
> More build output cleaning up
> Support of "make -s": do not output anything of the build itself
> Allow "make -w" generate its usual output
>
> Avi Kivity (1):
> git-send-email: configurable bcc and chain-reply-to
>
> Frank Lichtenheld (1):
> cvsserver: Use Merged response instead of Update-existing for merged files
>
> Jakub Narebski (1):
> gitweb: Don't escape attributes in CGI.pm HTML methods
>
> Jeff King (1):
> New fast-import test case for valid tree sorting
>
> Jim Meyering (1):
> I like the idea of the new ':/<oneline prefix>' notation, and gave it
>
> Johannes Schindelin (15):
> fetch & clone: do not output progress when not on a tty
> Fixup no-progress for fetch & clone
> Make git-revert & git-cherry-pick a builtin
> diff: support reading a file from stdin via "-"
> diff --no-index: support /dev/null as filename
> Get rid of the dependency to GNU diff in the tests
> cherry-pick: Suggest a better method to retain authorship
> format-patch: add --inline option and make --attach a true attachment
> bundle: fix wrong check of read_header()'s return value & add tests
> git-bundle: avoid packing objects which are in the prerequisites
> git-bundle: Make thin packs
> git-bundle: handle thin packs in subcommand "unbundle"
> git-bundle: die if a given ref is not included in bundle
> git-bundle: prevent overwriting existing bundles
> git-bundle: only die if pack would be empty, warn if ref is skipped
>
> Johannes Sixt (3):
> Add core.symlinks to mark filesystems that do not support symbolic links.
> Handle core.symlinks=false case in merge-recursive.
> Tell multi-parent diff about core.symlinks.
>
> Junio C Hamano (14):
> diff-ni: fix the diff with standard input
> format-patch --attach: not folding some long headers.
> Post 1.5.0.3 cleanup
> fsck: fix broken loose object check.
> unpack_sha1_file(): detect corrupt loose object files.
> fsck: exit with non-zero status upon errors
> git-bundle: fix pack generation.
> revision walker: Fix --boundary when limited
> revision traversal: retire BOUNDARY_SHOW
> git-bundle: various fixups
> revision traversal: SHOWN means shown
> git-bundle: make verify a bit more chatty.
> revision --boundary: fix stupid typo
> revision --boundary: fix uncounted case.
>
> Li Yang (1):
> gitweb: Change to use explicitly function call cgi->escapHTML()
>
> Linus Torvalds (1):
> Re-fix get_sha1_oneline()
>
> Paolo Bonzini (3):
> git-config: document --rename-section, provide --remove-section
> git-archimport: allow remapping branch names
> git-commit: add a --interactive option
>
> Santi Béjar (2):
> t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetch
> t/t5515-fetch-merge-logic.sh: Add two more tests
>
> Shawn O. Pearce (31):
> cherry-pick: Bug fix 'cherry picked from' message.
> Make 'make' quieter while building git
> Make 'make' quiet by default
> Display the null SHA-1 as the base for an OBJ_OFS_DELTA.
> Fix mmap leak caused by reading bad indexes.
> Don't build external_grep if its not used
> General const correctness fixes
> Use uint32_t for all packed object counts.
> Use uint32_t for pack-objects counters.
> Use off_t when we really mean a file offset.
> Use off_t in pack-objects/fast-import when we mean an offset
> Cast 64 bit off_t to 32 bit size_t
> Preallocate memory earlier in fast-import
> Move post-update hook to after all other activity
> Don't run post-update hook unless a ref changed
> Refactor run_update_hook to be more useful
> Refactor handling of error_string in receive-pack
> Teach receive-pack to run pre-receive/post-receive hooks
> Use atomic updates to the fast-import mark file
> Allow fast-import frontends to reload the marks table
> Switch to run_command_v_opt in revert
> Remove unused run_command variants
> Start defining a more sophisticated run_command
> Split run_command into two halves (start/finish)
> Teach run_command how to setup a stdin pipe
> Refactor run_command error handling in receive-pack
> Split back out update_hook handling in receive-pack
> Change {pre,post}-receive hooks to use stdin
> Remove unnecessary casts from fast-import
> Simplify closing two fds at once in run-command.c
> Fix t5510-fetch's use of sed
>
> Xavier Maillard (1):
> contrib/emacs: Use non-interactive function to byte-compile files
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-03-22 17:08 ` Steven Grimm
@ 2007-03-22 21:30 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-22 21:30 UTC (permalink / raw)
To: Steven Grimm; +Cc: Git Mailing List
Steven Grimm <koreth@midwinter.com> writes:
> Will you be applying your patch for the "checkout fails if something
> is a file in one branch and a directory in another" problem? I realize
> it's not a complete solution, but it's at least a significant
> improvement over the current behavior, and I don't imagine it breaks
> anything else.
If I understand correctly, the patch is already broken. Rather,
the patch itself may be correct but it exposes more breakages
that currently is hidden only because we do not replace bunch of
files in a subdirectory with a single file in the index thanks
to the "too strict" check that is bothering you. Lifting that
check with the previous patch would make it either fail to
notice other local changes (which is worse), or mistakenly say
there is a local change when there is none (which is not better
but not worse). In particular, I think it is highly suspicious
what the current code with the patch does to paths that
immediately follow the directory to be removed, although I
stopped looking into this issue, as we already said this will
not be dealt with in 1.5.1.
In short, I do not think the patch is suitable for production,
as the cure seems worse than the disease.
That does not mean anybody is forbidden to look into a fix in
the meantime. I am just saying I do not expect it to happen
before 1.5.1.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-03-13 8:49 ` Junio C Hamano
2007-03-13 9:26 ` Junio C Hamano
2007-03-22 17:08 ` Steven Grimm
@ 2007-03-25 8:32 ` Junio C Hamano
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-03-25 8:32 UTC (permalink / raw)
To: git
On the 'maint' front, there are a handful gitweb fixes, but
there is nothing major. I'll perhaps do a v1.5.0.6 if I have
time when I do the v1.5.1-rc2.
I allowed a handful new features to the 'master' side, contrary
to the promise of -rc1 which is supposed to be 'no new features,
only fixes'. They should be safe changes, though.
- 'git-diff --quiet' optimizes tree-level comparison by exiting
early when it finds one difference. This speeds up path-limited
form of git-rev-list and git-log significantly.
- 'git-bisect run <script>' can be used to automate simple
bisection.
Notable fixes since -rc1 includes:
- 'git-clone -q' supresses the "walk" and "got" noises while
fetching over http.
- 'git-revert' does not add duplicated abbreviated commit
object name on the title line anymore.
- With core.legacyheaders turned off, zero-length loose object
was incorrectly judged corrupt.
- 'git-apply' with core.autocrlf generated bogus results.
- path-limited 'git-bisect' terminated too early before finding
the guilty commit.
- the sample update hook does not generate change notification
e-mails anymore.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.0.5.
Jakub Narebski (4):
gitweb: Fix "next" link in commit view
gitweb: Don't escape attributes in CGI.pm HTML methods
gitweb: Fix not marking signoff lines in "log" view
gitweb: Add some installation notes in gitweb/INSTALL
Li Yang (1):
gitweb: Change to use explicitly function call cgi->escapHTML()
Michael S. Tsirkin (1):
fix typo in git-am manpage
Peter Eriksen (1):
Documentation/pack-format.txt: Clear up description of types.
* The 'master' branch has these since v1.5.1-rc1.
Alex Riesen (2):
Document --quiet option to git-diff
Use diff* with --exit-code in git-am, git-rebase and git-merge-ours
Andy Parkins (2):
update-hook: abort early if the project description is unset
update-hook: remove e-mail sending hook.
Brandon Casey (1):
prefer "git COMMAND" over "git-COMMAND" in gitk
Chris Wright (1):
make git clone -q suppress the noise with http fetch
Christian Couder (6):
Bisect: implement "git bisect run <cmd>..." to automatically bisect.
Documentation: bisect: reformat some paragraphs.
Documentation: bisect: reword one paragraph.
Documentation: bisect: reformat more paragraphs.
Documentation: bisect: add some titles to some paragraphs.
Documentation: bisect: make a comment fit better in the man page.
Eric Wong (1):
gitk: bind <F5> key to Update (reread commits)
James Bowes (1):
Replace remaining instances of strdup with xstrdup.
Johannes Schindelin (5):
xdiff/xutils.c(xdl_hash_record): factor out whitespace handling
Add a HOWTO for setting up a standalone git daemon
Provide some technical documentation for shallow clones
t4118: be nice to non-GNU sed
git-revert: Revert revert message to old behaviour
Junio C Hamano (12):
blame: micro-optimize cmp_suspect()
blame: cmp_suspect is not "cmp" anymore.
Teach tree_entry_interesting() that the tree entries are sorted.
tree-diff: avoid strncmp()
tree_entry_interesting(): allow it to say "everything is interesting"
git-rebase: make 'rebase HEAD branch' work as expected.
git-apply: Do not free the wrong buffer when we convert the data for writeout
checkout: report where the new HEAD is upon detaching HEAD
git-bisect: typofix
git-bisect.sh: properly dq $GIT_DIR
Fix path-limited "rev-list --bisect" termination condition.
git-am documentation: describe what is taken from where.
Linus Torvalds (6):
Fix loose object uncompression check.
Don't ever return corrupt objects from "parse_object()"
Be more careful about zlib return values
Remove "pathlen" from "struct name_entry"
Initialize tree descriptors with a helper function rather than by hand.
Switch over tree descriptors to contain a pre-parsed entry
Michael S. Tsirkin (1):
git-merge: Put FETCH_HEAD data in merge commit message
Nicolas Pitre (10):
clean up the delta base cache size a bit
use a LRU eviction policy for the delta base cache
don't ever allow SHA1 collisions to exist by fetching a pack
index-pack: use hash_sha1_file()
index-pack: more validation checks and cleanups
improve checkout message when asking for same branch
minor git-prune optimization
update HEAD reflog when branch pointed to by HEAD is directly modified
make it more obvious that temporary files are temporary files
write_sha1_from_fd() should make new objects read-only
Santi Béjar (1):
git-fetch: Fix single_force in append_fetch_head
Shawn O. Pearce (1):
contrib/continuous: a continuous integration build manager
Uwe Kleine-König (1):
Bisect: convert revs given to good and bad to commits
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-02-14 23:54 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-14 23:54 UTC (permalink / raw)
To: git
The next maintenance release from 'maint' branch will be 1.5.0.1
when we accumulate enough fixes worth to cut one.
The next feature release from 'master' will be 1.5.1. I'd like
to have 6 to 8 weeks between releases, so that will be around
end of March or mid-April. Maybe we can talk about what the
theme for that release should be in a separate thread.
Now the big release is over, I should be able to slow a little
bit down for a few days.
* The 'maint' branch has these fixes since v1.5.0
Alexandre Julliard (2):
git-daemon: Avoid leaking the listening sockets into child processes.
sha1_file.c: Round the mmap offset to half the window size.
Junio C Hamano (8):
Documentation: Drop full-stop from git-fast-import title.
cmd-list: add git-remote
Makefile: update check-docs target
Clarify two backward incompatible repository options.
Still updating 1.5.0 release notes.
Add RelNotes 1.5.0.1
Make sure packedgitwindowsize is multiple of (pagesize * 2)
GIT-VERSION-FILE: check ./version first.
Nicolas Pitre (1):
Minor corrections to release notes
* The 'master' branch has these since v1.5.0; this includes all
of the above.
Alexandre Julliard (2):
git-daemon: Avoid leaking the listening sockets into child processes.
sha1_file.c: Round the mmap offset to half the window size.
Andy Parkins (2):
Only show log entries for new revisions in hooks--update
The "table-of-contents" in the update hook script should match the body
Johannes Schindelin (2):
Teach revision machinery about --reverse
teach diff machinery about --ignore-space-at-eol
Junio C Hamano (18):
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
Make merge-base a built-in.
Allow in_merge_bases() to take more than one reference commits.
Remove git-resolve.
Remove git-diff-stages.
Add link to v1.5.0 documentation.
blame: --show-stats for easier optimization work.
Documentation: Drop full-stop from git-fast-import title.
cmd-list: add git-remote
Makefile: update check-docs target
Document --ignore-space-at-eol option.
Add RelNotes 1.5.1
Point top-level RelNotes link at 1.5.1 release notes being prepared.
Clarify two backward incompatible repository options.
Still updating 1.5.0 release notes.
Add RelNotes 1.5.0.1
Make sure packedgitwindowsize is multiple of (pagesize * 2)
GIT-VERSION-FILE: check ./version first.
Nicolas Pitre (1):
Minor corrections to release notes
^ permalink raw reply [flat|nested] 601+ messages in thread
* [ANNOUNCE] GIT 1.5.0-rc4
@ 2007-02-07 23:21 Junio C Hamano
2007-02-13 5:15 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-07 23:21 UTC (permalink / raw)
To: git
The latest and hopefully the last rc for GIT 1.5.0 is available
at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.rc4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.rc4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.rc4.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.0.rc4-1.$arch.rpm (RPM)
Late comers are independent reflog for HEAD, git-blame that
annotates the working tree files (and "--contents <file>"), and
git-fast-import.
----------------------------------------------------------------
Changes since v1.5.0-rc3 are as follows:
Alex Riesen (1):
Avoid ActiveState Perl IO in t800[12]
Andy Parkins (2):
doc: hooks.txt said post-commit default sends an email, it doesn't
git-for-each-ref doesn't return "the bit after $GIT_DIR/refs"
Aneesh Kumar K.V (1):
blameview: Support browsable functionality to blameview.
David Kågedal (1):
git-blame: an Emacs minor mode to view file with git-blame output.
Eric Wong (2):
git-svn: do not let Git.pm warn if we prematurely close pipes
Disallow invalid --pretty= abbreviations
Gerrit Pape (1):
git-archimport: initial import needs empty directory
Horst H. von Brand (1):
Call make always with CFLAGS in git.spec
Johannes Schindelin (4):
Teach the '@{...}' notation to git-log -g
Update the documentation for the new '@{...}' syntax
Commands requiring a work tree must not run in GIT_DIR
fast-import: Fix compile warnings
Junio C Hamano (36):
create_symref(): do not assume pathname from git_path() persists long enough
detached HEAD -- finishing touches
Use "git checkout -q" in git-bisect
Tutorial: fix asciidoc formatting of "git add" section.
Tutorial-2: Adjust git-status output to recent reality.
core-tutorial: http reference link fix
fix reflog entries for "git-branch"
honor GIT_REFLOG_ACTION in git-commit
Why is it bad to rewind a branch that has already been pushed out?
combine-diff: special case --unified=0
show-branch -g: default to the current branch.
git-clone --reference: saner handling of borrowed symrefs.
Revert "Allow branch.*.merge to talk about remote tracking branches."
Rename get_ident() to fmt_ident() and make it available to outside
t9200: Work around HFS+ issues.
bisect: it needs to be done in a working tree.
git-blame: no rev means start from the working tree file.
Add pretend_sha1_file() interface.
Use pretend_sha1_file() in git-blame and git-merge-recursive.
blame: document --contents option
Teach git-remote add to fetch and track
Fix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGS
gitk: Use show-ref instead of ls-remote
git-push: allow globbing wildcard refspec.
gitweb: fix mismatched parenthesis
annotate: fix for cvsserver.
S_IFLNK != 0140000
Remove contrib/colordiff
Add deprecation notices.
Remove git-merge-recur
git-clone --reference: work well with pack-ref'ed reference repository
for-each-reflog: fix case for empty log directory
t4200: skip gc-rerere test on systems with non GNU date.
git-add -i: update removed path correctly.
Documentation: Add gfi to the main command list.
GIT v1.5.0-rc4
Linus Torvalds (2):
pager: Work around window resizing bug in 'less'
Fix "git log -z" behaviour
Mark Levedahl (2):
gitk - remove trailing whitespace from a few lines.
Make gitk work reasonably well on Cygwin.
Michael (1):
Documentation: add KMail in SubmittingPatches
Mike Coleman (1):
Fix some documentation typos and grammar
Nicolas Pitre (14):
make reflog filename independent from struct ref_lock
lock_ref_sha1_basic(): remember the original name of a ref when resolving it
enable separate reflog for HEAD
add reflog entries for HEAD when detached
move create_symref() past log_ref_write()
add logref support to git-symbolic-ref
add reflog when moving HEAD to a new branch
reword the detached head message a little again
add a quiet option to git-checkout
prevent HEAD reflog to be interpreted as current branch reflog
provide a nice @{...} syntax to always mean the current branch reflog
scan reflogs independently from refs
Enable HEAD@{...} and make it independent from the current branch
Let git-checkout always drop any detached head
Pavel Roskin (2):
git-config --rename-section could rename wrong section
Assorted typo fixes
Robin Rosenberg (1):
Why is it bad to rewind a branch that has already been pushed out?
Shawn O. Pearce (113):
Created fast-import, a tool to quickly generating a pack from blobs.
Added automatic index generation to fast-import.
Cleaned up memory allocation for object_entry structs.
Refactored fast-import's internals for future additions.
Added basic command handler to fast-import.
Implemented branch handling and basic tree support in fast-import.
Added tree and commit writing to fast-import.
Implement blob ID validation in fast-import.
Converted fast-import to a text based protocol.
Changed fast-import's pack header creation to use pack.h
Allow symlink blobs in trees during fast-import.
Fixed segfault in fast-import after growing a tree.
Converted fast-import to accept standard command line parameters.
Added mark store/find to fast-import.
Added branch load counter to fast-import.
Implemented 'tag' command in fast-import.
Implemented tree reloading in fast-import.
Round out memory pool allocations in fast-import to pointer sizes.
Remove branch creation command from fast-import.
Moved from command to after data to help cvs2svn.
Account for tree entry memory costs in fast-import.
Added option to export the marks table when fast-import terminates.
Added --branch-log to option to fast-import.
Fixed GPF in fast-import caused by unterminated linked list.
Fixed compile error in fast-import.
Map only part of the generated pack file at any point in time.
Added 'reset' command to clear a branch's tree.
Don't crash fast-import if no branch log was requested.
Converted hash memcpy/memcmp to new hashcpy/hashcmp/hashclr.
Implemented tree delta compression in fast-import.
Recycle data buffers for tree generation in fast-import.
Reuse the same buffer for all commits/tags in fast-import.
Replace ywrite in fast-import with the standard write_or_die.
Correct tree corruption problems in fast-import.
Additional fast-import tree delta corruption cleanups.
Fix repository corruption when using marks for modified blobs.
Support creation of merge commits in fast-import.
Allow creating branches without committing in fast-import.
Improve reuse of sha1_file library within fast-import.
Misc. type cleanups within fast-import.
Restructure fast-import to support creating multiple packfiles.
Remove unnecessary duplicate_count in fast-import.
Implemented manual packfile switching in fast-import.
Don't create a final empty packfile in fast-import.
Optimize index creation on large object sets in fast-import.
Implemented automatic checkpoints within fast-import.
Print the packfile names to stdout from fast-import.
Corrected buffer overflow during automatic checkpoint in fast-import.
Use uintmax_t for marks in fast-import.
Replace redundant yread() with read_in_full() in fast-import.
Reuse sha1 in packed_git in fast-import.
Use .keep files in fast-import during processing.
Ensure we close the packfile after creating it in fast-import.
Remove unnecessary pack_fd global in fast-import.
Correct max_packsize default in fast-import.
Correct object_count type and stat output in fast-import.
Print out the edge commits for each packfile in fast-import.
Corrected BNF input documentation for fast-import.
Correct a few types to be unsigned in fast-import.
Declare no-arg functions as (void) in fast-import.
Correct packfile edge output in fast-import.
Always use struct pack_header for pack header in fast-import.
Use fixed-size integers when writing out the index in fast-import.
Remove unnecessary options from fast-import.
Support delimited data regions in fast-import.
Create test case for fast-import.
Reduce value duplication in t9300-fast-import.
Accept 'inline' file data in fast-import commit structure.
Pull out remote listing functions in git-remote.
Teach 'git remote' how to cleanup stale tracking branches.
Cleanup prepare_packed_git_one to reuse install_packed_git.
Correct comment in prepare_packed_git_one.
Refactor open_packed_git to return an error code.
Don't find objects in packs which aren't available anymore.
Don't leak file descriptors from unavailable pack files.
Cleanup subcommand documentation for git-remote.
Keep untracked files not involved in a merge.
Default GIT_MERGE_VERBOSITY to 5 during tests.
bash: Remove short option completions for branch/checkout/diff.
bash: Classify cat-file and reflog as plumbing.
bash: Complete long options to git-add.
bash: Add space after unique command name is completed.
bash: Classify more commends out of completion.
bash: Support unique completion on git-config.
bash: Support unique completion when possible.
bash: Support internal revlist options better.
Include checkpoint command in the BNF.
Reduce memory usage of fast-import.
Show an example of deleting commits with git-rebase.
bash: Support completion on git-cherry.
bash: Hide diff-stages from completion.
bash: Offer --prune completion for git-gc.
bash: Hide git-resolve, its deprecated.
bash: Support --add completion to git-config.
bash: Support git-bisect and its subcommands.
Don't support shell-quoted refnames in fast-import.
Initial draft of fast-import documentation.
bash: Support git-rebase -m continuation completion.
bash: Complete git-remote subcommands.
Remove --branch-log from fast-import.
Correct compiler warnings in fast-import.
Correct minor style issue in fast-import.
Correct fast-import timezone documentation.
Remove unnecessary null pointer checks in fast-import.
Minor fast-import documentation corrections.
Support RFC 2822 date parsing in fast-import.
Don't do non-fastforward updates in fast-import.
Minor timestamp related documentation corrections for fast-import.
Teach fast-import how to clear the internal branch content.
Teach fast-import how to sit quietly in the corner.
Dump all refs and marks during a checkpoint in fast-import.
Don't crash fast-import if the marks cannot be exported.
Add a Tips and Tricks section to fast-import's manual.
Simon 'corecode' Schubert (1):
Allow forcing of a parent commit, even if the parent is not a direct one.
Stelian Pop (1):
Add hg-to-git conversion utility.
Uwe Kleine-König (1):
add replay and log to the usage string of git-bisect
Yasushi SHOJI (1):
gitweb: Convert project name to UTF-8
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-02-07 23:21 [ANNOUNCE] GIT 1.5.0-rc4 Junio C Hamano
@ 2007-02-13 5:15 ` Junio C Hamano
2007-02-13 10:15 ` Johannes Schindelin
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13 5:15 UTC (permalink / raw)
To: git
It feels like it took me forever to get here, but this is almost
it. The short-log looks huge but only because Shawn's git-gui
is now included.
Unless there is some last minute showstopper, the final will be
cut on Wednesday. Should I give it a catchy codename? ;-)
* The 'master' branch has these since v1.5.0-rc4
Alexandre Julliard (3):
diff.c: Reuse the pprint_rename function for diff --summary output.
diff.c: Properly quote file names in diff --summary output.
diff.c: More logical file name quoting for renames in diffstat.
Aneesh Kumar K.V (1):
blameview: Move the commit info to a pane below the blame window.
David Kågedal (5):
Handle uncommitted changes and cache descriptions
git-blame.el: improve color handling
git-blame.el: blame unsaved changes
git-blame.el: Doc fixes and cleanup
git-blame.el: Autoupdate while editing
Dotan Barak (1):
Make it easier to override path to asciidoc command
Eric Wong (1):
git-svn: correctly handle boolean options via git-config
Jakub Narebski (2):
git-blame: Add Emacs Lisp file headers and GNU GPL boilerplate
git-blame: Change installation instructions
James Bowes (1):
Read cvsimport options from repo-config
Johannes Schindelin (4):
for_each_reflog_ent: be forgiving about missing message
log --reflog: honour --relative-date
format-patch -n: make sorting easier by padding number
log --reflog: use dwim_log
Junio C Hamano (11):
create_symref(): create leading directories as needed.
reflog: handle $name => remotes/%s/HEAD mapping consistently for logs
Documentation/git-pull: describe default behaviour and config interactions
git-fetch: document automatic tag following.
wt_status_prepare(): clean up structure initialization.
diff_flush_name(): take struct diff_options parameter.
t4016: test quoting funny pathnames in diff output
Documentation: git-rebase -C<n>
Teach git-am to pass -p option down to git-apply
Add discussion section to git-tag documentation.
Add RPM target for git-gui
Linus Torvalds (1):
git reflog show
Mark Levedahl (2):
Make gitk save and restore the user set window position.
Make gitk save and restore window pane position on Linux and Cygwin.
Matthias Lederhofer (1):
git merge documentation: -m is optional
Michael Loeffler (1):
import-tars: brown paper bag fix for file mode.
Michael S. Tsirkin (3):
Update git-log and git-show documentation
add -C[NUM] to git-am
Document that git-am can read standard input.
Mukund (1):
Fixed some typos in git-repack docs
Nicolas Pitre (1):
remove mailmap.linux
René Scharfe (1):
Avoid ugly linewrap in git help
Shawn O. Pearce (313):
git-gui: Initial revision.
git-gui: Additional early feature development.
git-gui: Fixed UI layout problems on Windows.
git-gui: Corrected keyboard bindings on Windows, improved state management.
git-gui: Verify we should actually perform a commit when asked to do so.
git-gui: Finished commit implementation.
git-gui: Implemented amended commits.
git-gui: Misc. nit type of bug fixes.
git-gui: Started construction of fetch and push operations.
git-gui: Worked around environment variable problems on Windows.
git-gui: Reorganized startup procedure to ensure gitdir is right.
git-gui: Fix menu item accelerator display on Mac OS X.
git-gui: Correctly handle CR vs. LF within the console of fetch.
git-gui: Check for fetch or push command failure and denote it.
git-gui: Don't complain if no .git/remotes exist.
git-gui: Added current TODO list.
git-gui: Last minute idea about fetch shortcuts.
git-gui: Automatically reopen any console closed by the user.
git-gui: Cache all repo-config data in an array.
git-gui: Added support for pulling from default branch of a remote.
git-gui: Updated TODO list now that pull is starting to work.
git-gui: Corrected diff-index/diff-files protocol parsing errors.
git-gui: Performance improvements for large file sets.
git-gui: More performance improvements to rescan logic.
git-gui: Flip commit message buffer and diff area.
git-gui: Added repack database menu option, to invoke git repack.
git-gui: Allow the user to disable update-index --refresh during rescan.
git-gui: Grab the index lock while running pull.
git-gui: Pluralize timestamps within the options menu.
git-gui: Disable pull menu items when the index is locked.
git-gui: Don't let the user pull into an uncommitted working directory.
git-gui: Update TODO list.
git-gui: Bug fix for bad variable reference in display_file.
git-gui: Changed term 'check-in' to 'include'.
git-gui: Show only the abbreviated SHA1 after committing.
git-gui: Cache the GIT_COMMITTER_IDENT value on first sign-off.
git-gui: Save window geometry to .git/config during exit.
git-gui: Change accelerator for "Include All" to M1-I.
git-gui: Created edit menu and basic editing bindings.
git-gui: Clear undo/redo stack when loading a message file from disk.
git-gui: Updated TODO list now that geometry is stored.
git-gui: Always indicate the file in the diff viewer.
git-gui: Correctly handle files containing LF in their name.
git-gui: Efficiently update the UI after committing.
git-gui: Use catch rather than array names to check file.
git-gui: Rename difffont/mainfont variables.
git-gui: Use native tk_messageBox for errors.
git-gui: Cleaned up error message formatting.
git-gui: Simplified format of geometry configuration.
git-gui: Misc. formatting cleanups.
git-gui: Misc. bug fixes for mouse click crashes.
git-gui: Added context menus for consoles and commit message buffer.
git-gui: Fix mouse cursor behavior when in widgets.
git-gui: Teach sign off to be more intelligent.
git-gui: Corrected font used for options menu items.
git-gui: Honor system font and let user configure fonts.
git-gui: Allow the user to change the diff viewer font size.
git-gui: Refresh a file if it has an empty diff.
git-gui: Make use of the Tk font system rather than faking it.
git-gui: Improve right click context menu binding on all platforms.
git-gui: Rename quitting global to is_quitting.
git-gui: Use arrow cursor rather than left_ptr.
git-gui: Refactor options menu into an options dialog.
git-gui: Allow the user to manipulate the fonts from the options panel.
git-gui: Supply progress feedback when running update-index.
git-gui: Minor options dialog UI cleanups.
git-gui: Added Options... menu item to end of diff context menu.
git-gui: Use 'after 1' to post UI rather than tkwait.
git-gui: Correct bugs in font config handling.
git-gui: Hide non-commit related commands when invoked as git-citool.
git-gui: Don't load the global options unless necessary.
git-gui: Allow the user to disable diff stat summary during pull.
git-gui: Run the pre-commit hook in the background.
git-gui: Remove the commit_active global variable.
git-gui: Added post-commit invocation after the commit is done.
git-gui: Always use eq/ne for string comparsions.
git-gui: Reshow diff if we sent the file to update-index.
git-gui: Cleanup diff construction code to prepare for more options.
git-gui: Allow the user to control the number of context lines in a diff.
git-gui: Sort the list of paths being updated in the index.
git-gui: Use a smaller pipe buffer for update-index.
git-gui: Allow the user to copy name of the file in the diff viewer.
git-gui: Correct language for M_/A_ status codes.
git-gui: Display status on left in diff header.
git-gui: Minor UI layout improvements for console windows.
git-gui: Reverted file name text field to a label.
git-gui: By default don't allow partially included files.
git-gui: Refactor mouse clicking on file names/icons.
git-gui: Narrow the no differences information message.
git-gui: Implemented multiple selection in file lists.
git-gui: Refactor update_status -> rescan.
git-gui: Provide an after-rescan script to rescan.
git-gui: Allow update_index to also run a script when it completes.
git-gui: Automatically update-index all included files before commit.
git-gui: Disable diff actions when no diff is active.
git-gui: Created makefile to install the program.
git-gui: Correctly handle GIT_DIR environment variable.
git-gui: Create Windows shortcut icons for git-gui.
git-gui: Protect ourselves from funny GIT_DIR/working directory setups.
git-gui: Handle ' within paths when creating Windows shortcuts.
git-gui: Only populate a fetch or push if we have an action.
git-gui: Create a .app file on MacOS X if requested.
git-gui: Display error dialog on Mac OS X when no .git found.
git-gui: Make initial commits work properly.
git-gui: Only reshow diff when really necessary.
git-gui: Refactor file state representations.
git-gui: Add menu option to include only selected files.
git-gui: Misc. comment formatting cleanups.
git-gui: Start UI with the index locked.
git-gui: Remove completed items from TODO list.
git-gui: Toggle between new commit and amend commit modes.
git-gui: Verify the user has GIT_COMMITTER_IDENT before comitting.
git-gui: Rephrase rescan before commit informational message.
git-gui: Allow adding untracked files in selection.
git-gui: Don't create PkgInfo on Mac OS X "desktop icons".
git-gui: Teach the gui how to uninclude a file.
git-gui: Make consecutive icon clicks toggle included status of a file.
git-gui: Correct toggling of deleted file status.
git-gui: Fix list loading corruption introduced by 1461c5f3.
git-gui: Describe deleted symlinks in a more friendly way.
git-gui: Correct toggling of added/untracked status for new files.
git-gui: Updated TODO list now that a task is complete.
git-gui: Refactored diff line display formatting logic.
git-gui: Restore the all important shebang line.
git-gui: Update in memory states after commit.
git-gui: Correct some state matchings for include/remove.
git-gui: Improve handling of merge commits.
git-gui: Allow users to run fsck-objects from the gui.
git-gui: Don't save amended commit message buffer.
git-gui: Reworded verify console title.
git-gui: Seperate out the database operations in project menu.
git-gui: Rename Project menu to Repository.
git-gui: Added about dialog box.
git-gui: Be more Macintosh like.
git-gui: Make the copyright notice serve double duty.
git-gui: Include the Tcl/Tk version in the about dialog.
git-gui: Abstract out windows platform test to is_Windows proc.
git-gui: Correct is_MacOSX platform test.
git-gui: Warn Cygwin users about possible environment issues.
git-gui: Added configuration editor TODO list.
git-gui: Refactor M1 binding selection.
git-gui: Added menu command to visualize all branches.
git-gui: Don't start 'gitk --all' on Mac OS X.
git-gui: Improve pull error dialogs.
git-gui: Added revert changes command.
git-gui: Display the current branch.
git-gui: Support file state MD (modified/deleted).
git-gui: Created Branch menu.
git-gui: Parse off refs/remotes when showing current branch.
git-gui: Abort on not implemented branch switching.
git-gui: Automatically skip tracking branches in branch menu.
git-gui: Rename all_branches -> all_heads.
git-gui: Misc. comment and formatting cleanups.
git-gui: Started implementation of switch_branch.
git-gui: Set a proper title on our revert confirm dialog box.
git-gui: Updated todo list.
git-gui: Enable resolution of merge conflicts.
git-gui: Auto-update any A? or M? files during rescan.
git-gui: Reworded 'Include' to 'Add' to match core Git.
git-gui: Created very crude Tools menu, to support miga.
git-gui: Show all fetched branches for remote pulls.
git-gui: Run git-gc rather than git-repack.
git-gui: Corrected behavior of deleted (but existing in HEAD) files.
git-gui: Correct wording of the revert confirmation dialog.
git-gui: Work around odd cygpath bug on Windows.
git-gui: Change more 'include' language to 'add'.
git-gui: Hide the ugly bash command line from the windows desktop icon.
git-gui: Modified makefile to embed version into git-gui script.
git-gui: Display the git-gui version in the Help->About dialog.
git-gui: Display the full GPL copyright notice in about dialog.
git-gui: Ensure version number is always current.
git-gui: Allow the user to copy the version data to the clipboard.
git-gui: Don't offer my miga hack if its configuration file isn't present.
git-gui: Suggest when running 'git gc' may be worthwhile.
git-gui: Refactor reponame computation.
git-gui: Cleanup usage of gitdir global variable.
git-gui: Allow [gitdir ...] to act as [file join [gitdir] ...].
git-gui: Make the gitk starting message match our usual format.
git-gui: Display the directory we are entering during startup.
git-gui: Start file status display refactoring.
git-gui: Convert UI to use 'staged for commit' interface.
git-gui: Correct DD file state to be only D_.
git-gui: Remove invalid DM state.
git-gui: Cleanup state descriptions.
git-gui: Refactor add/remove proc names to align with reality.
git-gui: Add or unstage based on the specific icon used.
git-gui: Refactor the revert (aka checkout-index) implementation.
git-gui: Refactor the add to commit state filters.
git-gui: Simplify printing of index info to update-index.
git-gui: Only permit selection in one list at a time.
git-gui: Pad the cancel/save buttons in the options window.
git-gui: Implemented create branch GUI.
git-gui: Bind M1-N to create branch.
git-gui: Implemented local branch deletion.
git-gui: Allow users to delete branches merged upstream.
git-gui: Allow creating branches from tracking heads.
git-gui: Use borders on text fields in branch dialog.
git-gui: Remove 'Allow Partially Added Files' option.
git-gui: Move commit_prehook into commit_tree.
git-gui: Improve the branch delete confirmation dialogs.
git-gui: Don't delete the test target branch.
git-gui: Attempt to checkout the new branch after creation.
git-gui: Refactor current_diff -> current_diff_path.
git-gui: Remove combined diff showing behavior.
git-gui: Improve the display of merge conflicts.
git-gui: Improve diff --cc viewing for unmerged files.
git-gui: Fix bug in unmerged file display.
git-gui: Clear diff from viewer if the side changed.
git-gui: Correct disappearing unstaged files.
git-gui: Add Refresh to diff viewer context menu.
git-gui: Correct unmerged file detection at commit time.
git-gui: Pad new branch name input box.
git-gui: Use a grid layout for branch dialog.
git-gui: Improve the merge check interface for branch deletion.
git-gui: Change rude error popup to info popup.
git-gui: Correctly ignore '* Unmerged path' during diff.
git-gui: Make diff viewer colors match gitk's defaults.
git-gui: Never line wrap in file lists.
git-gui: Don't offer tracking branches if none exist.
git-gui: Give a better error message on an empty branch name.
git-gui: Allow user to specify a branch name pattern.
git-gui: Improve keyboard traversal in dialogs.
git-gui: Fully select a field when entering into it.
git-gui: Automatically toggle the relevant radio buttons.
git-gui: Correctly categorize tracking branches and heads.
git-gui: Update todo list with finished and new items.
git-gui: Slightly tweak new window geometry.
git-gui: Create missing branch head on initial commit.
git-gui: Don't format the mode line of a diff.
git-gui: Force an update-index --refresh on unchanged files.
git-gui: Don't attempt to tag new file/deleted file headers in diffs.
git-gui: Fix 'Select All' action on Windows.
git-gui: Ignore 'No newline at end of file' marker line.
git-gui: Always start a rescan on an empty diff.
git-gui: Don't show content of untracked binary files.
git-gui: Limit display of large untracked files.
git-gui: When possible show the type of an untracked file.
git-gui: Don't try to tag the 'Binary files * and * differ' line.
git-gui: Remove spurious newline in untracked file display.
git-gui: Honor system encoding for filenames.
git-gui: Handle commit encoding better.
git-gui: Display database stats (count-objects -v) on demand.
git-gui: Implement basic branch switching through read-tree.
git-gui: Use system default labelframe bordering.
git-gui: Display the size of the pack directory.
git-gui: Only allow Refresh in diff context menu when we have a diff.
git-gui: Allow staging/unstaging individual diff hunks.
git-gui: Elide CRs appearing in diff output from display.
git-gui: Cleanup end-of-line whitespace in commit messages.
git-gui: Unset unnecessary UI setup variable.
git-gui: Force focus to the diff viewer on mouse click.
git-gui: Support 'Visualize All Branches' on Mac OS X.
git-gui: Pad the database statistics dialog window.
git-gui: Prefer Tk's entry widget over a 1 line text field.
git-gui: Remove Pull menu and cleanup Branch/Fetch/Push menus.
git-gui: Don't switch branches if changing to the current branch.
git-gui: Maintain the same file list for diff during refresh.
git-gui: Always use lsearch -exact, to prevent globbing.
git-gui: Added arbitrary branch pushing support.
git-gui: Remove no longer used pull from remote code.
git-gui: Always use -v option to push.
git-gui: Refactor console success/failure handling.
git-gui: Use builtin version of 'git gc'.
git-gui: Implement local merge operations.
git-gui: Let users abort with `reset --hard` type logic.
git-gui: Update status bar during a merge.
git-gui: Don't allow users to commit a bad octopus merge.
git-gui: Don't allow merges in the middle of other things.
git-gui: Always offer scrollbars for branch lists.
git-gui: Support merge.summary, merge.verbosity.
git-gui: Reword meaning of merge.summary.
git-gui: Offer quick access to the HTML formatted documentation.
git-gui: Test for Cygwin differently than from Windows.
git-gui: Implemented file browser and incremental blame.
git-gui: Improve the icons used in the browser display.
git-gui: Display the current branch name in browsers.
git-gui: Allow users to edit user.name, user.email from options.
git-gui: Use -M and -C when running blame.
git-gui: Correctly handle spaces in filepaths.
git-gui: Display original filename and line number in blame.
git-gui: Install column headers in blame viewer.
git-gui: Use a grid layout for the blame viewer.
git-gui: Assign background colors to each blame hunk.
Correct ^0 asciidoc syntax in fast-import docs.
Correct some language in fast-import documentation.
Correct spelling of fast-import in docs.
tar archive frontend for fast-import.
git-gui: Update known branches during rescan.
git-gui: Support keyboard traversal in browser.
git-gui: Replace \ with \\ when showing paths.
git-gui: Refactor single_commit to a proc.
git-gui: Separate transport/branch menus from multicommit.
git-gui: Optionally save commit buffer on exit.
git-gui: View blame from the command line.
git-gui: Select subcommands like git does.
git-gui: Relabel the Add All action.
git-gui: Use git-config now over git-repo-config.
git-gui: Redesign the display of annotated files.
git-gui: Jump to the first annotation block as soon as its available.
git-gui: Improve annotated file display.
git-gui: Focus into blame panels on Mac OS.
git-gui: Stop deleting gitk preferences.
fast-import: Hide the pack boundary commits by default.
fast-import: Add tip about importing renames.
bash: Hide git-fast-import.
fast-import: Support reusing 'from' and brown paper bag fix reset.
git-gui: Allow gitexecdir, INSTALL to be set by the caller.
git-gui: Rename GIT_VERSION to GITGUI_VERSION.
git-gui: Generate a version file on demand.
git-gui: Handle gitgui tags in version gen.
git-gui: Guess our version accurately as a subproject.
git-gui: Change base version to 0.6.
Link git-gui into the master Makefile.
Theodore Ts'o (2):
Print a sane error message if an alias expands to an invalid git command
Allow aliases to expand to shell commands
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 5:15 ` What's in git.git (stable) Junio C Hamano
@ 2007-02-13 10:15 ` Johannes Schindelin
2007-02-13 17:33 ` Junio C Hamano
2007-02-13 13:56 ` Matthias Lederhofer
2007-02-13 14:33 ` Bill Lear
2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-13 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Mon, 12 Feb 2007, Junio C Hamano wrote:
> It feels like it took me forever to get here, but this is almost
> it.
Congratulations!
> The short-log looks huge but only because Shawn's git-gui is now
> included.
So, it's a huge-log?
> Unless there is some last minute showstopper, the final will be
> cut on Wednesday. Should I give it a catchy codename? ;-)
Oh yes, yes, yes! (To both.)
Ciao,
Dscho
P.S.: How about "The frotzy Nitfol"?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 10:15 ` Johannes Schindelin
@ 2007-02-13 17:33 ` Junio C Hamano
2007-02-13 18:21 ` Randal L. Schwartz
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13 17:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Unless there is some last minute showstopper, the final will be
>> cut on Wednesday. Should I give it a catchy codename? ;-)
>
> Oh yes, yes, yes! (To both.)
>
> Ciao,
> Dscho
>
> P.S.: How about "The frotzy Nitfol"?
I am starting to regret asking that question. I initially had
something related to Feb 14th in mind when I sent the message,
but realized it is not as universal as I thought after reading
an Wikipedia article.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 17:33 ` Junio C Hamano
@ 2007-02-13 18:21 ` Randal L. Schwartz
2007-02-13 18:37 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Randal L. Schwartz @ 2007-02-13 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I am starting to regret asking that question. I initially had
Junio> something related to Feb 14th in mind when I sent the message,
Junio> but realized it is not as universal as I thought after reading
Junio> an Wikipedia article.
The "would have been Randal's Parents' 46th wedding anniversary had
they not divorced 28 years ago" release? :)
And I was born exactly nine months later. Amazing. Not only that, my brother
was born the same day a year later. Can anyone say "wedding night and first
anniversary"? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 18:21 ` Randal L. Schwartz
@ 2007-02-13 18:37 ` Johannes Schindelin
2007-02-13 22:02 ` Jimmy Tang
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-13 18:37 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
Hi,
On Tue, 13 Feb 2007, Randal L. Schwartz wrote:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> I am starting to regret asking that question. I initially had
> Junio> something related to Feb 14th in mind when I sent the message,
> Junio> but realized it is not as universal as I thought after reading
> Junio> an Wikipedia article.
>
> The "would have been Randal's Parents' 46th wedding anniversary had
> they not divorced 28 years ago" release? :)
>
> And I was born exactly nine months later. Amazing. Not only that, my brother
> was born the same day a year later. Can anyone say "wedding night and first
> anniversary"? :)
Okay, okay, I already had one shot, but here's another:
<silly>
Let's call it "American PI minus one" release. Since Americans love to
fsck up the dates, they would write the month first, then the day,
which ends up being 2.14, which is exactly PI - 1 rounded to three digits!
Alternatively, since they really write 2/14, we could call it the "one
seventh" release...
</silly>
Enough already,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 18:37 ` Johannes Schindelin
@ 2007-02-13 22:02 ` Jimmy Tang
2007-02-13 23:31 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Jimmy Tang @ 2007-02-13 22:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randal L. Schwartz, Junio C Hamano, git
Hi All,
On Tue, Feb 13, 2007 at 07:37:03PM +0100, Johannes Schindelin wrote:
>
> <silly>
> Let's call it "American PI minus one" release. Since Americans love to
> fsck up the dates, they would write the month first, then the day,
> which ends up being 2.14, which is exactly PI - 1 rounded to three digits!
>
> Alternatively, since they really write 2/14, we could call it the "one
> seventh" release...
> </silly>
>
in a totally different direction...
how about code naming the release(s) with british slang words? since
``git'' is a fairly common british slang word (also used quite abit in
ireland too) to describe an unlikeable person. and since the release is
going to be cut on the 14th, how about calling it the "snog" release :)
not too sure how appropriate it would be to name releases after british
slang words as they usually have inappropriate meanings.
Jimmy
--
Jimmy Tang
Trinity Centre for High Performance Computing,
Lloyd Building, Trinity College Dublin, Dublin 2, Ireland.
http://www.tchpc.tcd.ie/ | http://www.tchpc.tcd.ie/~jtang
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 22:02 ` Jimmy Tang
@ 2007-02-13 23:31 ` Linus Torvalds
0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2007-02-13 23:31 UTC (permalink / raw)
To: Jimmy Tang; +Cc: Johannes Schindelin, Randal L. Schwartz, Junio C Hamano, git
On Tue, 13 Feb 2007, Jimmy Tang wrote:
>
> how about code naming the release(s) with british slang words? since
> ``git'' is a fairly common british slang word (also used quite abit in
> ireland too) to describe an unlikeable person. and since the release is
> going to be cut on the 14th, how about calling it the "snog" release :)
I think that's a great naming convention for releases!
Linus
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 5:15 ` What's in git.git (stable) Junio C Hamano
2007-02-13 10:15 ` Johannes Schindelin
@ 2007-02-13 13:56 ` Matthias Lederhofer
2007-02-13 16:58 ` Junio C Hamano
2007-02-13 14:33 ` Bill Lear
2 siblings, 1 reply; 601+ messages in thread
From: Matthias Lederhofer @ 2007-02-13 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Unless there is some last minute showstopper, the final will be
> cut on Wednesday. Should I give it a catchy codename? ;-)
Documentation/git-checkout.txt still needs an update about reflogs
with detached HEAD (the paragraph starting with "The command would
refuse [..]").
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 13:56 ` Matthias Lederhofer
@ 2007-02-13 16:58 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-02-13 16:58 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Unless there is some last minute showstopper, the final will be
>> cut on Wednesday. Should I give it a catchy codename? ;-)
> Documentation/git-checkout.txt still needs an update about reflogs
> with detached HEAD (the paragraph starting with "The command would
> refuse [..]").
Thanks. I'd do the following.
---
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 55c9289..e4ffde4 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -103,22 +103,12 @@ by any branch (which is natural --- you are not on any branch).
What this means is that you can discard your temporary commits
and merges by switching back to an existing branch (e.g. `git
checkout master`), and a later `git prune` or `git gc` would
-garbage-collect them.
-
-The command would refuse to switch back to make sure that you do
-not discard your temporary state by mistake when your detached
-HEAD is not pointed at by any existing ref. If you did want to
-save your state (e.g. "I was interested in the fifth commit from
-the top of 'master' branch", or "I made two commits to fix minor
-bugs while on a detached HEAD" -- and if you do not want to lose
-these facts), you can create a new branch and switch to it with
-`git checkout -b newbranch` so that you can keep building on
-that state, or tag it first so that you can come back to it
-later and switch to the branch you wanted to switch to with `git
-tag that_state; git checkout master`. On the other hand, if you
-did want to discard the temporary state, you can give `-f`
-option (e.g. `git checkout -f master`) to override this
-behaviour.
+garbage-collect them. If you did this by mistake, you can ask
+the reflog for HEAD where you were, e.g.
+
+------------
+$ git log -g -2 HEAD
+------------
EXAMPLES
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 5:15 ` What's in git.git (stable) Junio C Hamano
2007-02-13 10:15 ` Johannes Schindelin
2007-02-13 13:56 ` Matthias Lederhofer
@ 2007-02-13 14:33 ` Bill Lear
2007-02-13 14:37 ` Bill Lear
2 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-02-13 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Monday, February 12, 2007 at 21:15:41 (-0800) Junio C Hamano writes:
>It feels like it took me forever to get here, but this is almost
>it. The short-log looks huge but only because Shawn's git-gui
>is now included.
>
>Unless there is some last minute showstopper, the final will be
>cut on Wednesday. Should I give it a catchy codename? ;-)
How about "Wodin"?
Bill
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 14:33 ` Bill Lear
@ 2007-02-13 14:37 ` Bill Lear
2007-02-13 17:18 ` Randal L. Schwartz
0 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-02-13 14:37 UTC (permalink / raw)
To: Junio C Hamano, git
On Tuesday, February 13, 2007 at 08:33:22 (-0600) Bill Lear writes:
>On Monday, February 12, 2007 at 21:15:41 (-0800) Junio C Hamano writes:
>>It feels like it took me forever to get here, but this is almost
>>it. The short-log looks huge but only because Shawn's git-gui
>>is now included.
>>
>>Unless there is some last minute showstopper, the final will be
>>cut on Wednesday. Should I give it a catchy codename? ;-)
>
>How about "Wodin"?
Actually, I think "Wotan" is it...
Bill
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-13 14:37 ` Bill Lear
@ 2007-02-13 17:18 ` Randal L. Schwartz
0 siblings, 0 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2007-02-13 17:18 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes:
Bill> Actually, I think "Wotan" is it...
Wotan Clang?
(Sideways reference to Wu-Tang Clan "music" group.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* [ANNOUNCE] GIT 1.5.0-rc3
@ 2007-02-01 0:26 Junio C Hamano
2007-02-04 9:36 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-01 0:26 UTC (permalink / raw)
To: git; +Cc: linux-kernel
It's been a week and a half, and here comes the -rc3
http://www.kernel.org/pub/software/scm/git/
git-1.5.0-rc3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0-rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0-rc3.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.0-rc3-1.$arch.rpm (RPM)
Hopefully this will be the last -rc before the final 1.5.0.
This contains the "git user's manual" by J. Bruce Fields. While
it still has its own "To Do" section, it has already been in a
very good shape for some time, giving information with coherence
and guiding a new user in a carefully chosen order of topics
into much more pleasant git experience than before.
----------------------------------------------------------------
Changes since v1.5.0-rc2 are as follows:
Alex Riesen (5):
Insert ACTIVESTATE_STRING in Git.pm
Force Activestate Perl to tie git command pipe handle to a handle class
Cleanup uninitialized value in chomp
Allow default core.logallrefupdates to be overridden with template's config
Fix git-update-index to work with relative pathnames.
Alexandre Julliard (1):
vc-git.el: Take into account the destination name in vc-checkout.
Andy Parkins (5):
New files in git weren't being downloaded during CVS update
If abbrev is set to zero in git-describe, don't add the unique suffix
Allow the tag signing key to be specified in the config file
UNIX reference time of 1970-01-01 00:00 is UTC timezone, not local time zone
Heavily expanded update hook to send more useful emails than the old hook
Aneesh Kumar K.V (2):
blameview: Use git-cat-file to read the file content.
Update git-cat-file documentation
Bill Lear (1):
Document --check option to git diff.
David Kågedal (1):
Improved error message from git-rebase
Eric Wong (1):
git-svn: remove leading slash when printing removed directories
J. Bruce Fields (31):
Documentation: add git user's manual
Documentation: expand preface and todo's
Documentation: git-rebase discussion, miscellaneous user-manual updates
Documentation: more user-manual todo's
Documentation: reorder development section, todo's
Documentation: begin discussion of git-remote in user manual
Documentation: rev-list -> rev-parse, other typos, start examples
user manual: answer some comments from Junio
user-manual: replace init-db by init
user-manual: reindent
user-manual: rewrap, fix heading levels
user-manual: add "quick start" as chapter 1
user-manual: minor quickstart reorganization
user-manual: clarify difference between tag and branch
user-manual: update references discussion
user-manual: update git-gc discussion
user-manual: stub discussion of fsck and reflog
user-manual: reorganize fetch discussion, add internals, etc.
user-manual: git-fsck, dangling objects
user-manual: fsck-objects -> fsck
user-manual: repo-config -> config
user-manual: add references to git-config man page
user-manual: typo fix
user-manual: fix a header level
user-manual: reflogs, other recovery
user-manual: rewrap a few long lines
user-manual: minor "TODO" updates
user-manual: document git-show-branch example
user-manual: SHA1 -> object name
user-manual: point to README for gitweb information
user-manual: todo's
Jakub Narebski (3):
Documentation/config.txt: Document config file syntax better
t/t1300-repo-config.sh: value continued on next line
Documentation/config.txt: Correct info about subsection name
Jason Riedy (1):
Use inttypes.h rather than stdint.h.
Jeff King (4):
format-patch: fix bug with --stdout in a subdirectory
contrib/vim: update syntax for changed commit template
diffcore-pickaxe: fix infinite loop on zero-length needle
Add a sample program 'blameview' to show how to use git-blame --incremental
Johannes Schindelin (2):
annotate: use pager
reflog inspection: introduce shortcut "-g"
Johannes Sixt (1):
Add a missing fork() error check.
Junio C Hamano (43):
User manual: fix typos in examples
Documentation/tutorial-2: Fix interesting typo in an example.
Revert "prune: --grace=time"
Make sure git_connect() always give two file descriptors.
is_repository_shallow(): prototype fix.
shallow repository: disable unsupported operations for now.
git-gc: do not run git-prune by default.
cvsimport: activate -a option, really.
.mailmap: fix screw-ups in Uwe's name
honor --author even with --amend, -C, and -c.
reflog gc: a tag that does not point at a commit is not a crime.
git-checkout -m: fix merge case
git-daemon documentation on enabling services.
ls-remote and clone: accept --upload-pack=<path> as well.
Refactor the pack header reading function out of receive-pack.c
Allow fetch-pack to decide keeping the fetched pack without exploding
fetch-pack: remove --keep-auto and make it the default.
Consolidate {receive,fetch}.unpackLimit
Allow non-developer to clone, checkout and fetch more easily.
parse-remote: do not barf on a remote shorthand without any refs to fetch.
show-branch -g: default to HEAD
Documentation: pack-refs --all vs default behaviour
Make sure we do not write bogus reflog entries.
git-merge: leave sensible reflog message when used as the first level UI.
create_symref: check error return from open().
write_in_full: size_t is unsigned.
Don't force everybody to call setup_ident().
git-blame --porcelain: quote filename in c-style when needed.
Update describe documentation.
Document 'git-blame --incremental'
git-fsck-objects is now synonym to git-fsck
Two small typofixes.
lock_any_ref_for_update(): do not accept malformatted refs.
git-commit -s: no extra space when sign-offs appear at the end already.
git-blame: somewhat better commenting.
git-send-email: remove debugging output.
Fix git-tag -u
Documentation: "git-checkout <tree> <path>" takes any tree-ish
t9200: Re-code non-ascii path test in UTF-8
t9200: do not test -x bit if the filesystem does not support it.
git main documentation: point at the user's manual.
Do not use hardcoded path to xhmtl.xsl to generate user's manual
GIT v1.5.0-rc3
Linus Torvalds (5):
fsck-objects: refactor checking for connectivity
Fix seriously broken "git pack-refs"
Add dangling objects tips.
git-blame --incremental
git-push through git protocol
Mark Wooding (3):
wt-status: Actually accept `color.status.BLAH' configuration variables.
Documentation/config.txt: Fix documentation of colour config tweaks.
Make fsck and fsck-objects be builtins.
Nicolas Pitre (3):
fix suggested branch creation command when detaching head
git-log -g --pretty=oneline should display the reflog message
tone down the detached head warning
Peter Eriksen (2):
sha1_file.c: Avoid multiple calls to find_pack_entry().
Documentation: --amend cannot be combined with -c/-C/-F.
René Scharfe (1):
git-blame --incremental: don't use pager
Sam Vilain (1):
contrib/emacs/vc-git.el: support vc-version-other-window
Santi Béjar (1):
git-fetch: Allow fetching the remote HEAD
Shawn O. Pearce (6):
Remove unnecessary found variable from describe.
Teach git-describe to display distances from tags.
Compute accurate distances in git-describe before output.
Teach for-each-ref about a little language called Tcl.
Don't coredump on bad refs in update-server-info.
Escape --upload-pack from expr.
Simon 'corecode' Schubert (1):
Replace perl code with pure shell code
Tom Prince (1):
Rename git-repo-config to git-config.
Uwe Kleine-König (2):
rename --exec to --upload-pack for fetch-pack and peek-remote
make --upload-pack option to git-fetch configurable
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-02-01 0:26 [ANNOUNCE] GIT 1.5.0-rc3 Junio C Hamano
@ 2007-02-04 9:36 ` Junio C Hamano
2007-02-04 18:51 ` Jeff King
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-04 9:36 UTC (permalink / raw)
To: git
Thanks everybody for helping to tie the loose ends for the next
release.
Thanks to Nico's handful updates, I think his "reflog on HEAD
itself" series is ready for inclusion, although tonight's update
still has it parked in 'next' (I did try out 'next' with his
latest for a couple of hours today). I've already updated the
draft release notes for 1.5.0 (v1.5.0.txt in todo branch), with
its inclusion in mind.
I've re-read the three tutorials and tried to fix them up
somewhat to match the recent reality. I'd appreciate somebody
can look at JBF's user manual.
Several things to note (in the following, substitute $gmane with
http://article.gmane.org/gmane.comp.version-control.git):
- Working around Tk geometry problem, especially on non Linux+X
platforms. I've forwarded Mark Levedahl's patches
($gmane/38361) to Paul Mackerras for his blessing; hopefully
he can Ack and/or suggest improvements. I'd really like to
have them in 1.5.0 in some form.
- Nico's "reflog on HEAD". I'll merge this tomorrow (I just
ran out of time today). I will re-try to break its "git
reflog expire --stale-fix --all" before actually merging it,
though.
- Reverting the patch to allow tracking branch names as the
value of branch.*.merge ($gmane/38621). I think it is a good
idea to revert this before 1.5.0 gets out; just haven't got
around to do so.
- Teaching "git blame" to also use the working tree files
and/or index. I actually think defaulting to working tree
when an explicit HEAD is not given (and --cached to use the
one in the index) makes a lot of sense, but I haven't got
around to code the latter yet. Not defaulting to HEAD
changes semantics, so if we ever are going to do it, I think
we should do so before 1.5.0.
- Preventing push from updating the current branch of non-bare
repository. I think doing so unconditionally is a bad idea
(and I have Linus's veto to back it up $gmane/38592), but I
suspect most people would want the default to be less
confusing to new people. If we are ever going to forbid by
default and allow pusher to force, that would be a behaviour
change and it would be better to do so before 1.5.0.
- We might want to allow git-push to use the wildcard refspec,
like git-fetch does, for symmetry. It would make the
mothership-satellite arrangement much more natural
($gname/38549). Unfortunately I haven't had a chance to
start coding it. I think however this could be added post
1.5.0.
- "git remote add -t -f -m" and rewrite of "git clone" based on
it ($gmane/38470, $gmane/38545). While I think this leads us
in right direction, I do not think 1.5.0 needs to wait for
it. Certainly I do not want to reimplement "git clone"
before 1.5.0, although I think the additions to "git remote add"
are relatively safe.
- Catering to filesystems whose readdir() returns pathnames
that are different from what are used when they were creat()ed
will not happen ($gmane/38620).
* The 'master' branch has these since v1.5.0-rc3.
Andy Parkins (1):
doc: hooks.txt said post-commit default sends an email, it doesn't
Eric Wong (2):
git-svn: do not let Git.pm warn if we prematurely close pipes
Disallow invalid --pretty= abbreviations
Johannes Schindelin (2):
Teach the '@{...}' notation to git-log -g
Update the documentation for the new '@{...}' syntax
Junio C Hamano (9):
detached HEAD -- finishing touches
Use "git checkout -q" in git-bisect
Tutorial: fix asciidoc formatting of "git add" section.
Tutorial-2: Adjust git-status output to recent reality.
core-tutorial: http reference link fix
fix reflog entries for "git-branch"
honor GIT_REFLOG_ACTION in git-commit
Why is it bad to rewind a branch that has already been pushed out?
combine-diff: special case --unified=0
Mike Coleman (1):
Fix some documentation typos and grammar
Nicolas Pitre (4):
reword the detached head message a little again
add a quiet option to git-checkout
prevent HEAD reflog to be interpreted as current branch reflog
provide a nice @{...} syntax to always mean the current branch reflog
Pavel Roskin (2):
git-config --rename-section could rename wrong section
Assorted typo fixes
Shawn O. Pearce (18):
Pull out remote listing functions in git-remote.
Teach 'git remote' how to cleanup stale tracking branches.
Cleanup prepare_packed_git_one to reuse install_packed_git.
Correct comment in prepare_packed_git_one.
Refactor open_packed_git to return an error code.
Don't find objects in packs which aren't available anymore.
Don't leak file descriptors from unavailable pack files.
Cleanup subcommand documentation for git-remote.
Keep untracked files not involved in a merge.
Default GIT_MERGE_VERBOSITY to 5 during tests.
bash: Remove short option completions for branch/checkout/diff.
bash: Classify cat-file and reflog as plumbing.
bash: Complete long options to git-add.
bash: Add space after unique command name is completed.
bash: Classify more commends out of completion.
bash: Support unique completion on git-config.
bash: Support unique completion when possible.
bash: Support internal revlist options better.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-04 9:36 ` What's in git.git (stable) Junio C Hamano
@ 2007-02-04 18:51 ` Jeff King
2007-02-04 19:12 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Jeff King @ 2007-02-04 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Feb 04, 2007 at 01:36:29AM -0800, Junio C Hamano wrote:
> - Teaching "git blame" to also use the working tree files
> and/or index. I actually think defaulting to working tree
> when an explicit HEAD is not given (and --cached to use the
> one in the index) makes a lot of sense, but I haven't got
> around to code the latter yet. Not defaulting to HEAD
> changes semantics, so if we ever are going to do it, I think
> we should do so before 1.5.0.
Just a thought, but it might be useful to blame the contents of an
arbitrary file (but starting the history at a given pathname). Something
like "git blame --contents /tmp/foo.c file.c", with contents defaulting
to "file.c". There's much discussion of editor interfaces, and this
leaves the possibility of git-blaming the contents of the editor buffer
(after writing it out to a temp file) without having to save changes to
the working tree file.
Admittedly, I think this will be rare, but if you git-blame from an
editor, it seems awkward to either be inaccurate (by blaming the last
saved working tree file, but comparing it to the buffer) or to save the
file as a side effect.
-Peff
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-04 18:51 ` Jeff King
@ 2007-02-04 19:12 ` Linus Torvalds
2007-02-04 20:58 ` Theodore Tso
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2007-02-04 19:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
On Sun, 4 Feb 2007, Jeff King wrote:
>
> Just a thought, but it might be useful to blame the contents of an
> arbitrary file (but starting the history at a given pathname). Something
> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
> to "file.c". There's much discussion of editor interfaces, and this
> leaves the possibility of git-blaming the contents of the editor buffer
> (after writing it out to a temp file) without having to save changes to
> the working tree file.
I agree, that probably would make most sense. If we do this at all. On the
other hand, I suspect that most editors would probably want to pipe the
contents to the program, not write it to a temp-file.
(I think it's a worthy feature, but Junio's patch wasn't exactly pretty,
so the question boils down to whether it's really worth it).
Linus
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-04 19:12 ` Linus Torvalds
@ 2007-02-04 20:58 ` Theodore Tso
2007-02-04 21:34 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2007-02-04 20:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 4 Feb 2007, Jeff King wrote:
> >
> > Just a thought, but it might be useful to blame the contents of an
> > arbitrary file (but starting the history at a given pathname). Something
> > like "git blame --contents /tmp/foo.c file.c", with contents defaulting
> > to "file.c". There's much discussion of editor interfaces, and this
> > leaves the possibility of git-blaming the contents of the editor buffer
> > (after writing it out to a temp file) without having to save changes to
> > the working tree file.
>
> I agree, that probably would make most sense. If we do this at all. On the
> other hand, I suspect that most editors would probably want to pipe the
> contents to the program, not write it to a temp-file.
... and use it with --incremental, as well. In emacs you can have the
annotation take place as it is being written out relatively easily, by
arranging to have a callback function get called each time more
information is handed back to emacs via a pipe.
- Ted
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-04 20:58 ` Theodore Tso
@ 2007-02-04 21:34 ` Jakub Narebski
2007-02-04 22:25 ` David Kågedal
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2007-02-04 21:34 UTC (permalink / raw)
To: git
Theodore Tso wrote:
> On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
>> On Sun, 4 Feb 2007, Jeff King wrote:
>>>
>>> Just a thought, but it might be useful to blame the contents of an
>>> arbitrary file (but starting the history at a given pathname). Something
>>> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
>>> to "file.c". There's much discussion of editor interfaces, and this
>>> leaves the possibility of git-blaming the contents of the editor buffer
>>> (after writing it out to a temp file) without having to save changes to
>>> the working tree file.
>>
>> I agree, that probably would make most sense. If we do this at all. On the
>> other hand, I suspect that most editors would probably want to pipe the
>> contents to the program, not write it to a temp-file.
>
> ... and use it with --incremental, as well. In emacs you can have the
> annotation take place as it is being written out relatively easily, by
> arranging to have a callback function get called each time more
> information is handed back to emacs via a pipe.
So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
pipe current contents of the buffer to "git blame --stdin --incremental
file.c" (where file.c is the name in tree/in HEAD).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-02-04 21:34 ` Jakub Narebski
@ 2007-02-04 22:25 ` David Kågedal
0 siblings, 0 replies; 601+ messages in thread
From: David Kågedal @ 2007-02-04 22:25 UTC (permalink / raw)
To: git; +Cc: jnareb
Jakub Narebski <jnareb@gmail.com> writes:
> Theodore Tso wrote:
>> On Sun, Feb 04, 2007 at 11:12:34AM -0800, Linus Torvalds wrote:
>>> On Sun, 4 Feb 2007, Jeff King wrote:
>>>>
>>>> Just a thought, but it might be useful to blame the contents of an
>>>> arbitrary file (but starting the history at a given pathname). Something
>>>> like "git blame --contents /tmp/foo.c file.c", with contents defaulting
>>>> to "file.c". There's much discussion of editor interfaces, and this
>>>> leaves the possibility of git-blaming the contents of the editor buffer
>>>> (after writing it out to a temp file) without having to save changes to
>>>> the working tree file.
>>>
>>> I agree, that probably would make most sense. If we do this at all. On the
>>> other hand, I suspect that most editors would probably want to pipe the
>>> contents to the program, not write it to a temp-file.
>>
>> ... and use it with --incremental, as well. In emacs you can have the
>> annotation take place as it is being written out relatively easily, by
>> arranging to have a callback function get called each time more
>> information is handed back to emacs via a pipe.
>
> So perhaps instead of "git blame --contents /tmp/foo.c file.c" we should
> have "cat /tmp/foo.c | git blame --stdin file.c", hmmm? Editor would then
> pipe current contents of the buffer to "git blame --stdin --incremental
> file.c" (where file.c is the name in tree/in HEAD).
But if we allow the standard convention of using - to mean stdin, the
--contents option would be more flexible, since "--contents -" would
just be a special case.
--
David Kågedal
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-01-27 8:05 Junio C Hamano
2007-01-27 8:59 ` Aneesh Kumar K.V
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-27 8:05 UTC (permalink / raw)
To: git
I am hoping that we can declare -rc3 and go into a deep freeze
after merging Shawn's "describe with accumulated commits since"
and Nico's "reflog on HEAD", perhaps by end of the month.
I haven't looked at the finishing touches from Shawn I received
tonight yet (it is parked in 'pu'). Nico's "reflog on HEAD"
looked good (also parked in 'pu'), but I think it needs to teach
the repack/prune/fsck/reflog-expire machinery about reflog
entries for HEAD -- otherwise a prune can make reflog useless
while your HEAD is detached (which may not be a big deal and
while I do not deeply care personally, it would be better to
consistently protect them like reflog entries for regular refs).
Although it is tempting to start futzing with prune and ancestry
traversal so that commits hidden by grafts are not lost by it,
which was brought up today, I think it should be better dealt
with after 1.5.0 (it is not a recent regression).
I'd like to take a look at JBF's manual and merge it early -- I
fed some small changes to him some time ago but did not have
chance to review its recent progress. It deserves attention
from wider audience.
* The 'master' branch has these since v1.5.0-rc2.
Alex Riesen (4):
Insert ACTIVESTATE_STRING in Git.pm
Force Activestate Perl to tie git command pipe handle to a handle class
Cleanup uninitialized value in chomp
Allow default core.logallrefupdates to be overridden with template's
config
Alexandre Julliard (1):
vc-git.el: Take into account the destination name in vc-checkout.
Andy Parkins (2):
New files in git weren't being downloaded during CVS update
If abbrev is set to zero in git-describe, don't add the unique suffix
Eric Wong (1):
git-svn: remove leading slash when printing removed directories
Jakub Narebski (3):
Documentation/config.txt: Document config file syntax better
t/t1300-repo-config.sh: value continued on next line
Documentation/config.txt: Correct info about subsection name
Jason Riedy (1):
Use inttypes.h rather than stdint.h.
Jeff King (3):
format-patch: fix bug with --stdout in a subdirectory
contrib/vim: update syntax for changed commit template
diffcore-pickaxe: fix infinite loop on zero-length needle
Johannes Schindelin (2):
annotate: use pager
reflog inspection: introduce shortcut "-g"
Junio C Hamano (25):
Documentation/tutorial-2: Fix interesting typo in an example.
Revert "prune: --grace=time"
Make sure git_connect() always give two file descriptors.
is_repository_shallow(): prototype fix.
shallow repository: disable unsupported operations for now.
git-gc: do not run git-prune by default.
cvsimport: activate -a option, really.
.mailmap: fix screw-ups in Uwe's name
honor --author even with --amend, -C, and -c.
reflog gc: a tag that does not point at a commit is not a crime.
git-checkout -m: fix merge case
git-daemon documentation on enabling services.
ls-remote and clone: accept --upload-pack=<path> as well.
Refactor the pack header reading function out of receive-pack.c
Allow fetch-pack to decide keeping the fetched pack without exploding
fetch-pack: remove --keep-auto and make it the default.
Consolidate {receive,fetch}.unpackLimit
Allow non-developer to clone, checkout and fetch more easily.
parse-remote: do not barf on a remote shorthand without any refs to fetch.
show-branch -g: default to HEAD
Documentation: pack-refs --all vs default behaviour
Make sure we do not write bogus reflog entries.
git-merge: leave sensible reflog message when used as the first level UI.
create_symref: check error return from open().
write_in_full: size_t is unsigned.
Linus Torvalds (3):
fsck-objects: refactor checking for connectivity
Fix seriously broken "git pack-refs"
Add dangling objects tips.
Nicolas Pitre (1):
fix suggested branch creation command when detaching head
Peter Eriksen (2):
sha1_file.c: Avoid multiple calls to find_pack_entry().
Documentation: --amend cannot be combined with -c/-C/-F.
Sam Vilain (1):
contrib/emacs/vc-git.el: support vc-version-other-window
Shawn O. Pearce (1):
Remove unnecessary found variable from describe.
Uwe Kleine-König (2):
rename --exec to --upload-pack for fetch-pack and peek-remote
make --upload-pack option to git-fetch configurable
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-01-27 8:05 Junio C Hamano
@ 2007-01-27 8:59 ` Aneesh Kumar K.V
2007-01-27 18:06 ` J. Bruce Fields
2007-01-27 22:00 ` Junio C Hamano
2007-01-27 17:56 ` J. Bruce Fields
2007-01-28 19:34 ` Bill Lear
2 siblings, 2 replies; 601+ messages in thread
From: Aneesh Kumar K.V @ 2007-01-27 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>
> I'd like to take a look at JBF's manual and merge it early -- I
> fed some small changes to him some time ago but did not have
> chance to review its recent progress. It deserves attention
> from wider audience.
>
What about the final version of this doc
[DRAFT] Branching and merging with git from
http://www.gelato.unsw.edu.au/archives/git/0611/31902.html
-aneesh
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-01-27 8:05 Junio C Hamano
2007-01-27 8:59 ` Aneesh Kumar K.V
@ 2007-01-27 17:56 ` J. Bruce Fields
2007-01-28 19:34 ` Bill Lear
2 siblings, 0 replies; 601+ messages in thread
From: J. Bruce Fields @ 2007-01-27 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sat, Jan 27, 2007 at 12:05:56AM -0800, Junio C Hamano wrote:
> I'd like to take a look at JBF's manual and merge it early -- I
> fed some small changes to him some time ago but did not have
> chance to review its recent progress. It deserves attention
> from wider audience.
That would be great, thanks.
At this point I'm most interested in higher-level questions: Are things
in a sensible order? What's the most important material that's not
covered? Etc. Not that fixes to the details aren't helpful too, of
course.
It still feels really rough, so I'm expecting it to take some time
before we'd want to point newbies to it as the place to go for an
in-depth git introduction.
--b.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-01-27 8:05 Junio C Hamano
2007-01-27 8:59 ` Aneesh Kumar K.V
2007-01-27 17:56 ` J. Bruce Fields
@ 2007-01-28 19:34 ` Bill Lear
2007-01-28 20:06 ` Junio C Hamano
2 siblings, 1 reply; 601+ messages in thread
From: Bill Lear @ 2007-01-28 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Saturday, January 27, 2007 at 00:05:56 (-0800) Junio C Hamano writes:
>I am hoping that we can declare -rc3 and go into a deep freeze
>after merging Shawn's "describe with accumulated commits since"
>and Nico's "reflog on HEAD", perhaps by end of the month.
Was there any final decision on allowing pushes through git-daemon?
Bill
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2007-01-28 19:34 ` Bill Lear
@ 2007-01-28 20:06 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-28 20:06 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Bill Lear <rael@zopyra.com> writes:
> On Saturday, January 27, 2007 at 00:05:56 (-0800) Junio C Hamano writes:
>>I am hoping that we can declare -rc3 and go into a deep freeze
>>after merging Shawn's "describe with accumulated commits since"
>>and Nico's "reflog on HEAD", perhaps by end of the month.
>
> Was there any final decision on allowing pushes through git-daemon?
Not really. I personally think it is Ok as long as the default
stays disabled as Linus posted.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-01-10 8:24 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10 8:24 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (2):
Do not ignore a detected patchfile brokenness.
Fix "Do not ignore a detected patchfile brokenness."
* The 'master' branch has these since the last announcement.
Two rather big changes are included: sliding mmap; UTF-8 is
default for e-mail acceptance tools. I am slightly worried
about the interaction of the latter with git-rebase, though...
Alexandre Julliard (3):
git-apply: Remove directories that have become empty after deleting a file.
git-clone: Make sure the master branch exists before running cat on it.
git.el: Define the propertize function if needed, for XEmacs compatibility.
Andy Whitcroft (5):
ssh-upload: prevent buffer overrun
short i/o: clean up the naming for the write_{in,or}_xxx family
short i/o: fix calls to read to use xread or read_in_full
short i/o: fix calls to write to use xwrite or write_in_full
short i/o: fix config updates to use write_in_full
Brian Gernhardt (2):
Ignore git-init and git-remote
Auto-quote config values in config.c:store_write_pair()
Eric Wong (2):
git-svn: add --prefix= option to multi-init
git-svn: pass an unambiguous ref to rev-list when grafting-branches
J. Bruce Fields (2):
Documentation: clarify definition of "reachable"
Documentation: add git-remote man page
Jakub Narebski (2):
gitweb: Remove superfluous "|" in "commit" view
gitweb: Fix git_patchset_body not closing <div class="patch">
Jeff King (1):
get_tree_entry: map blank requested entry to tree root
Junio C Hamano (21):
pack-objects: fix use of use_pack().
mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
git-remote
builtin-prune: make file-scope static struct to an argument.
builtin-prune: separate ref walking from reflog walking.
Move traversal of reachable objects into a separate library.
reflog expire --fix-stale
reflog --fix-stale: do not check the same trees and commits repeatedly.
diff-index --cached --raw: show tree entry on the LHS for unmerged entries.
git-reset <tree> -- <path> restores absense of <path> in <tree>
Spell default packedgitlimit slightly differently
--utf8 is now default for 'git-am'
--prune is now default for 'pack-refs'
rm git-rerere.perl -- it is now a built-in.
merge-base: do not leak commit list
Do not ignore a detected patchfile brokenness.
Fix "Do not ignore a detected patchfile brokenness."
builtin-archive: do not free a tree held by the object layer.
git-am: should work when "--no-utf8 --utf8" is given
-u is now default for 'git-applymbox'
-u is now default for 'git-mailinfo'.
Jürgen Rühle (5):
Clarify syntax and role of git-add in status output
Improve "nothing to commit" part of status output
Support --amend on initial commit in status output
Improve cached content header of status output
Remove unnecessary git-rm --cached reference from status output
Martin Langhoff (6):
cvsimport: skip commits that are too recent
cvsimport: skip commits that are too recent (option and documentation)
cvsimport: document -S and -L options
cvsimport: cleanup temporary cvsps file
cvsserver: detect early of we are up to date and avoid costly rev-list
cvsserver: fix revision number during file adds
Michael Loeffler (1):
git-commit: do not fail to print the diffstat even if there is a file named HEAD
Nicolas Pitre (1):
"init-db" can really be just "init"
Pavel Roskin (1):
Fix warnings in sha1_file.c - use C99 printf format if available
Sasha Khapyorsky (1):
git-svnimport: fix edge revisions double importing
Shawn O. Pearce (25):
Replace unpack_entry_gently with unpack_entry.
Introduce new config option for mmap limit.
Refactor packed_git to prepare for sliding mmap windows.
Use off_t for index and pack file lengths.
Create read_or_die utility routine.
Refactor how we open pack files to prepare for multiple windows.
Replace use_packed_git with window cursors.
Loop over pack_windows when inflating/accessing data.
Document why header parsing won't exceed a window.
Unmap individual windows rather than entire files.
Fully activate the sliding window pack access.
Load core configuration in git-verify-pack.
Ensure core.packedGitWindowSize cannot be less than 2 pages.
Improve error message when packfile mmap fails.
Support unmapping windows on 'temporary' packfiles.
Create pack_report() as a debugging aid.
Test suite for sliding window mmap implementation.
Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
Release pack windows before reporting out of memory.
Replace mmap with xmmap, better handling MAP_FAILED.
Cleanup read_cache_from error handling.
Fix random segfaults in pack-objects.
Update packedGit config option documentation.
Increase packedGit{Limit,WindowSize} on 64 bit systems.
Don't die in git-http-fetch when fetching packs.
Stefan-W. Hahn (1):
Replacing the system call pread() with lseek()/xread()/lseek() sequence.
Steven Grimm (1):
Update git-svn manpage to remove the implication that SVN::* is optional.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-01-10 8:23 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10 8:23 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (2):
Do not ignore a detected patchfile brokenness.
Fix "Do not ignore a detected patchfile brokenness."
* The 'master' branch has these since the last announcement.
Two rather big changes are included: sliding mmap; UTF-8 is
default for e-mail acceptance tools. I am slightly worried
about the interaction of the latter with git-rebase, though...
Alexandre Julliard (3):
git-apply: Remove directories that have become empty after deleting a file.
git-clone: Make sure the master branch exists before running cat on it.
git.el: Define the propertize function if needed, for XEmacs compatibility.
Andy Whitcroft (5):
ssh-upload: prevent buffer overrun
short i/o: clean up the naming for the write_{in,or}_xxx family
short i/o: fix calls to read to use xread or read_in_full
short i/o: fix calls to write to use xwrite or write_in_full
short i/o: fix config updates to use write_in_full
Brian Gernhardt (2):
Ignore git-init and git-remote
Auto-quote config values in config.c:store_write_pair()
Eric Wong (2):
git-svn: add --prefix= option to multi-init
git-svn: pass an unambiguous ref to rev-list when grafting-branches
J. Bruce Fields (2):
Documentation: clarify definition of "reachable"
Documentation: add git-remote man page
Jakub Narebski (2):
gitweb: Remove superfluous "|" in "commit" view
gitweb: Fix git_patchset_body not closing <div class="patch">
Jeff King (1):
get_tree_entry: map blank requested entry to tree root
Junio C Hamano (21):
pack-objects: fix use of use_pack().
mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
git-remote
builtin-prune: make file-scope static struct to an argument.
builtin-prune: separate ref walking from reflog walking.
Move traversal of reachable objects into a separate library.
reflog expire --fix-stale
reflog --fix-stale: do not check the same trees and commits repeatedly.
diff-index --cached --raw: show tree entry on the LHS for unmerged entries.
git-reset <tree> -- <path> restores absense of <path> in <tree>
Spell default packedgitlimit slightly differently
--utf8 is now default for 'git-am'
--prune is now default for 'pack-refs'
rm git-rerere.perl -- it is now a built-in.
merge-base: do not leak commit list
Do not ignore a detected patchfile brokenness.
Fix "Do not ignore a detected patchfile brokenness."
builtin-archive: do not free a tree held by the object layer.
git-am: should work when "--no-utf8 --utf8" is given
-u is now default for 'git-applymbox'
-u is now default for 'git-mailinfo'.
Jürgen Rühle (5):
Clarify syntax and role of git-add in status output
Improve "nothing to commit" part of status output
Support --amend on initial commit in status output
Improve cached content header of status output
Remove unnecessary git-rm --cached reference from status output
Martin Langhoff (6):
cvsimport: skip commits that are too recent
cvsimport: skip commits that are too recent (option and documentation)
cvsimport: document -S and -L options
cvsimport: cleanup temporary cvsps file
cvsserver: detect early of we are up to date and avoid costly rev-list
cvsserver: fix revision number during file adds
Michael Loeffler (1):
git-commit: do not fail to print the diffstat even if there is a file named HEAD
Nicolas Pitre (1):
"init-db" can really be just "init"
Pavel Roskin (1):
Fix warnings in sha1_file.c - use C99 printf format if available
Sasha Khapyorsky (1):
git-svnimport: fix edge revisions double importing
Shawn O. Pearce (25):
Replace unpack_entry_gently with unpack_entry.
Introduce new config option for mmap limit.
Refactor packed_git to prepare for sliding mmap windows.
Use off_t for index and pack file lengths.
Create read_or_die utility routine.
Refactor how we open pack files to prepare for multiple windows.
Replace use_packed_git with window cursors.
Loop over pack_windows when inflating/accessing data.
Document why header parsing won't exceed a window.
Unmap individual windows rather than entire files.
Fully activate the sliding window pack access.
Load core configuration in git-verify-pack.
Ensure core.packedGitWindowSize cannot be less than 2 pages.
Improve error message when packfile mmap fails.
Support unmapping windows on 'temporary' packfiles.
Create pack_report() as a debugging aid.
Test suite for sliding window mmap implementation.
Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
Release pack windows before reporting out of memory.
Replace mmap with xmmap, better handling MAP_FAILED.
Cleanup read_cache_from error handling.
Fix random segfaults in pack-objects.
Update packedGit config option documentation.
Increase packedGit{Limit,WindowSize} on 64 bit systems.
Don't die in git-http-fetch when fetching packs.
Stefan-W. Hahn (1):
Replacing the system call pread() with lseek()/xread()/lseek() sequence.
Steven Grimm (1):
Update git-svn manpage to remove the implication that SVN::* is optional.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2007-01-02 0:07 Junio C Hamano
2007-01-07 7:43 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-01-02 0:07 UTC (permalink / raw)
To: git
A happy new year.
I think this is more-or-less it to start the -rc1 cycle.
I'll leave the window open for another week or so before people
come back from the christmas and new year break. I have not
been working on any of the potential changes other people talked
about recently on the list, but things like detached HEAD and
more generic per-branch customization may magically materialize
from somewhere as a robust and usable set of patches.
I also haven't reviewed the introductory documentation set
recently, which I think is necessary before the release.
I'll be sending out an updated draft for v1.5.0 release notes in a
separate message.
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: remove svnadmin dependency from the tests
git-svn: t/t9100-git-svn-basic: remove old check for NO_SYMLINK
git-svn: t/t91??-*: optimize the tests a bit
J. Bruce Fields (6):
Docs: update cvs-migration.txt to reflect clone's new default behavior
Documentation: update git-clone.txt for clone's new default behavior
Documentation: update glossary entry for "origin"
Documentation: update tutorial's discussion of origin
Documentation: update git-pull.txt for new clone behavior
Documentation: remove master:origin example from pull-fetch-param.txt
Junio C Hamano (12):
send-pack: fix pipeline.
Documentation: illustrate send-pack pipeline.
Update documentation for update hook.
send-pack.c: use is_null_sha1()
send-pack: tell pack-objects to use its internal rev-list.
Do not merge random set of refs out of wildcarded refs
i18n: do not leak 'encoding' header even when we cheat the conversion.
Update send-pack pipeline documentation.
fail pull/merge early in the middle of conflicted merge
git-fetch: remove .keep file at the end.
Strongly discourage --update-head-ok in fetch-options documentation.
Update clone/fetch documentation with --depth (shallow clone) option
Shawn O. Pearce (4):
Move better_branch_name above get_ref in merge-recursive.
Allow merging bare trees in merge-recursive.
Use merge-recursive in git-am -3.
Add test case for update hooks in receive-pack.
Theodore Tso (1):
Fix formatting for urls section of fetch, pull, and push manpages
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2007-01-02 0:07 Junio C Hamano
@ 2007-01-07 7:43 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-07 7:43 UTC (permalink / raw)
To: git
I'll do v1.4.4.4 from 'maint' to have grave bugfixes in an
"officially released version" tomorrow, although we will be in
stabilation period for v1.5.0 shortly.
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (2):
Fix infinite loop when deleting multiple packed refs.
pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
* The 'master' branch has these since the last announcement.
Alexandre Julliard (3):
git-clean: Fix the -q option.
git.el: Don't use --info-only when resolving a file.
git.el: Avoid setting font lock keywords before entering log-edit mode.
Andy Whitcroft (1):
send pack check for failure to send revisions list
Brian Gernhardt (1):
Add documentation for git-branch's color configuration.
Eric Wong (6):
instaweb: load Apache mime and dir modules if they are needed
git-svn: make multi-init less confusing
git-svn: update documentation for multi-{init|fetch}
git-svn: make --repack work consistently between fetch and multi-fetch
Documentation/git-svn: clarify dcommit, rebase vs pull/merge
git-svn: fix show-ignore
Fredrik Kuivinen (1):
instaweb: Nicer error message when the http daemon isn't found
J. Bruce Fields (1):
Documentation: tutorial editing
Jakub Narebski (9):
gitweb: Fix error in git_project_index subroutine
gitweb: Fix bug in git_difftree_body (was '!=' instead of 'ne')
gitweb: There can be empty patches (in git_patchset_body)
gitweb: Fix "Use of uninitialized value" warning in git_tags_body
gitweb: Fix error in git_patchest_body for file creation/deletion patch
gitweb: Fix error in "rename to"/"copy to" git diff header output
gitweb: Fix errors in git_patchset_body for empty patches
Revert "gitweb: There can be empty patches (in git_patchset_body)"
gitweb: Fix split patches output (e.g. file to symlink)
Junio C Hamano (9):
Remove unused variable (git-commit.sh)
fetch-pack: do not use lockfile structure on stack.
Fix infinite loop when deleting multiple packed refs.
tutorial: misc updates.
git-verify-tag: make sure we remove temporary file.
pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
rerere: Fix removal of already resolved path.
builtin-prune: memory diet.
Fix timestamp for test-tick
Lars Hjemli (2):
Skip excessive blank lines before commit body
Refactor print-functions in builtin-branch
Luben Tuikov (1):
Blame "linenr" link jumps to previous state at "orig_lineno"
René Scharfe (3):
Make check target depend on common-cmds.h
Remove shadowing variable from traverse_trees()
Set default "tar" umask to 002 and owner.group to root.root
Robert Fitzsimons (1):
gitweb: Fix shortlog only showing HEAD revision.
Santi Béjar (2):
Documentation/tutorial: misc updates
git-tag: add flag to verify a tag
Sasha Khapyorsky (2):
git-svnimport: support for incremental import
git-svnimport: clean svn path when accessing SVN repo
Steven Grimm (2):
Describe git-clone's actual behavior in the summary
Print a more accurate error message when we fail to create a lock file.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2006-12-31 8:07 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-31 8:07 UTC (permalink / raw)
To: git
I am happy that we are making steady progress towards v1.5.0,
especially with tonight's handful fixes from Shawn.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* The 'master' branch has these since the last announcement.
Jakub Narebski (1):
Add info about new test families (8 and 9) to t/README
Johannes Schindelin (1):
Fix yet another subtle xdl_merge() bug
Junio C Hamano (12):
Work around http-fetch built with cURL 7.16.0
t5400 send-pack test: try a bit more nontrivial transfer.
Revert "read_directory: show_both option."
Fix 'git add' with .gitignore
commit re-encoding: fix confusion between no and default conversion.
t3900: test log --encoding=none
Documentation: i18n commit log message notes.
Documentation: minor rewording for git-log and git-show pages.
Move commit reencoding parameter parsing to revision.c
commit-tree: cope with different ways "utf-8" can be spelled.
i18n: drop "encoding" header in the output after re-coding.
Documentation/config.txt (and repo-config manpage): mark-up fix.
Shawn O. Pearce (8):
Force core.filemode to false on Cygwin.
Use PATH_MAX constant for --bare.
Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT.
Automatically detect a bare git repository.
Remove unnecessary argc parameter from run_command_v.
Redirect update hook stdout to stderr.
Use /dev/null for update hook stdin.
Teach Git how to parse standard power of 2 suffixes.
Theodore Ts'o (1):
Fix formatting for urls section of fetch, pull, and push manpages
^ permalink raw reply [flat|nested] 601+ messages in thread
* [RFH] An early draft of v1.5.0 release notes
@ 2006-12-27 7:39 Junio C Hamano
2006-12-27 8:18 ` Shawn Pearce
` (4 more replies)
0 siblings, 5 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 7:39 UTC (permalink / raw)
To: git
This is still rough, but I think we have a pretty good idea what
will and what won't be in v1.5.0 by now, and end-of-year is a
good slow time to summarize what we have done.
One thing I am wondering is if delta from v1.4.4.3 is good
enough for the intended audience of this release notes. I am
reasonably sure that the name v1.5.0 will attract more people
than usual and there will be many people upgrading directly from
ancient versions such as v1.1.6 or v1.2.0, and there are a
handful "one-way-street upgrades" and quite a few user visible
changes that already have happened before v1.4.4. Namely:
- Pack-compatible loose object headers, introduced between
v1.4.1 and v1.4.2; repository cannot be read with ancient
version of git anymore -- this is a one-way street but
core.legacyheaders is still not enabled by default);
- delta-base-offset pack encoding, introduced between v1.4.2
and v1.4.3; this is also a one-way street.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timer users.
- 'git archive' superseded 'git tar' in v1.4.3;
- 'git pack-refs' appeared in v1.4.4;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is v1.4.0 invention.
In the following, I am assuming that jc/utf8 and jc/fsck-reflog
topics currently in 'next' will be part of v1.5.0.
-- >8 --
Updates in v1.5.0 since v1.4.4 series
-------------------------------------
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Say "git add ." if you want to.
- git-add tries to be more friendly to users by offering an
interactive mode.
- git-commit <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones (the latter is still supported).
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
used to track branches from the origin. New branches that
appear on the origin side after a clone is made are also
tracked automatically.
- git-clone used to be buggy and copied refs outside refs/heads
and refs/tags; it doesn't anymore.
- git-branch and git-show-branch know remote tracking branches.
- git-push can now be used to delete a remote branch or a tag.
* Reflog
- Reflog records the history of where the tip of each branch
was at each moment. This facility is enabled by default for
repositories with working trees, and can be accessed with the
"branch@{time}" and "branch@{Nth}" notation.
- "git show-branch" learned showing the reflog data with the
new --reflog option.
- The commits referred to by reflog entries are now protected
against pruning. The new command "git reflog expire" can be
used to truncate older reflog entries and entries that refer
to commits that have been pruned away previously.
Existing repositories that have been using reflog may get
complaints from fsck-objects; please run "git reflog expire
--all" first to remove reflog entries that refer to commits
that are no longer in the repository before attempting to
repack it.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
* Packed refs
- Repositories with hundreds of tags have been paying large
overhead, both in storage and in runtime. A new command,
git-pack-refs, can be used to "pack" them in more efficient
representation.
- Clones and fetches over dumb transports are now aware of
packed refs and can download from repositories that use
them.
* Configuration
- configuration related to colorize setting are consolidated
under color.* namespace (older diff.color.*, status.color.*
are still supported).
* Less external dependency
- We have been depended on "merge" program from RCS suite for
the file-level 3-way merge, but now we lost this dependency.
- The original implementation of git-merge-recursive which was
in Python has been removed; we have C implementation of it
now.
- git-shortlog is not in Perl anymore, and more importantly it
does not have to be piped output from git-log. It can
traverse the commit ancestry itself.
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects (which will never change).
A non UTF-8 commit encoding however _must_ be explicitly set
with i18n.commitencoding in the repository configuration;
otherwise git-commit-tree will complain if the log message does
not look like a valid UTF-8 string.
- A commit object recorded in non UTF-8 encoding records the
encoding i18n.commitencoding specified in the originating
repository in a new "encoding" header. This information is
used by git-log and friends to reencode the message to UTF-8
when displaying.
* User support
- Quite a lot of documentation updates.
- Bash completion scripts have been updated heavily.
- Better error messages for often used Porcelainish commands.
----------------------------------------------------------------
(shortlog since v1.4.4.3 here)
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
@ 2006-12-27 8:18 ` Shawn Pearce
2006-12-27 10:12 ` Jakub Narebski
` (3 subsequent siblings)
4 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-12-27 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
This is certainly a good idea. And your summary was pretty good
too, I enjoyed the read. This group has certainly accomplished
quite a bit lately!
Just a few comments:
> - Pack-compatible loose object headers, introduced between
> v1.4.1 and v1.4.2; repository cannot be read with ancient
> version of git anymore -- this is a one-way street but
> core.legacyheaders is still not enabled by default);
>
> - delta-base-offset pack encoding, introduced between v1.4.2
> and v1.4.3; this is also a one-way street.
Perhaps you can clarify that using these means the repository
cannot be used with an earlier version of Git? You may also want
to highlight why these features are good, answering the question
"Why should I enable them if it breaks backwards compatibility?".
Isn't the new packed-refs format also a one-way street? If you
use them for tags on a web server and the client is using a very
old http commit walker, what happens?
> - git-clone used to be buggy and copied refs outside refs/heads
> and refs/tags; it doesn't anymore.
I mentioned to you on #git this morning that I don't think this
is noteworthy for this release.
You missed talking about the mess of pack files created by git-push
now, especially with pushes over 100 objects. ;-)
> - git-push can now be used to delete a remote branch or a tag.
You should mention this requires server side support too. I read
that and assumed I could just upgrade my client and push to delete
- which isn't the case, and I know its not... but I still read it
that way.
> - "git show-branch" learned showing the reflog data with the
> new --reflog option.
I had hoped we could get 'git reflog show' into 1.5.0 but the
current discussion with Johannes seems like that's unlikely.
> - We have been depended on "merge" program from RCS suite for
> the file-level 3-way merge, but now we lost this dependency.
Perhaps just reword as:
We no longer require the "merge" program from the RCS suite.
All 3-way file-level merges are now done internally.
> - git-shortlog is not in Perl anymore, and more importantly it
> does not have to be piped output from git-log. It can
> traverse the commit ancestry itself.
The "traverse the commit ancestry itself" part is not very
readable for the average user. How about instead:
git-shortlog is no longer a Perl script. git-shortlog also
no longer requires output piped from git-log; it can accept
revision parameters directly on the command line.
--
Shawn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
2006-12-27 8:18 ` Shawn Pearce
@ 2006-12-27 10:12 ` Jakub Narebski
2006-12-27 10:24 ` Junio C Hamano
2006-12-27 10:50 ` Junio C Hamano
2006-12-27 12:06 ` Horst H. von Brand
` (2 subsequent siblings)
4 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-27 10:12 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
Very nice idea! Perhaps those release notes can find it's way into
either v1.5.0 commit, or v1.5.0 tag comment?
Just a few comments:
> - git-add without any argument does not add everything
> anymore. Say "git add ." if you want to.
>
> - git-add tries to be more friendly to users by offering an
> interactive mode.
Perhaps information that git-add can be used to add ignored files
with -f option should be added? Or is it not important enough?
> - The commits referred to by reflog entries are now protected
> against pruning. The new command "git reflog expire" can be
> used to truncate older reflog entries and entries that refer
> to commits that have been pruned away previously.
>
> Existing repositories that have been using reflog may get
> complaints from fsck-objects; please run "git reflog expire
> --all" first to remove reflog entries that refer to commits
> that are no longer in the repository before attempting to
> repack it.
That's a bit bad, as it forces to lose some info... but that
info was not that useful anyway.
> - A commit object recorded in non UTF-8 encoding records the
> encoding i18n.commitencoding specified in the originating
> repository in a new "encoding" header. This information is
> used by git-log and friends to reencode the message to UTF-8
> when displaying.
I don't quite like it. Why if someone uses different encoding
that utf-8 because his terminal is not set to utf-8? Having suddenly
what looks like garbage on output, while input was in local encoding
(and specified in i18n.commitencoding) is a bit suprising...
> ----------------------------------------------------------------
> (shortlog since v1.4.4.3 here)
I'd rather have description a la "what's cooking" here...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 10:12 ` Jakub Narebski
@ 2006-12-27 10:24 ` Junio C Hamano
2006-12-27 11:54 ` Johannes Schindelin
2006-12-27 12:12 ` Jakub Narebski
2006-12-27 10:50 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 10:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> That's a bit bad, as it forces to lose some info... but that
> info was not that useful anyway.
I am tired of listening to this useless FUD of yours. You lost
the information when you pruned away the underlying objects; you
are not losing information when you expire the reflog entries
that became useless long time ago.
> I don't quite like it. Why if someone uses different encoding
> that utf-8 because his terminal is not set to utf-8? Having suddenly
> what looks like garbage on output, while input was in local encoding
> (and specified in i18n.commitencoding) is a bit suprising...
If Luben wants UTF-8 in his project, but somebody he pulled from
was mistakenly used latin-1, then the commit pulled record
latin-1 while Luben has i18n.commitencoding in his repository
set to UTF-8. Output will be done in UTF-8 for Luben. For the
originator of that latin-1 commit, i18n.commitencoding says
latin-1 (and that was the only reason he managed to create such
a commit) and git show of that commit would not involve
recoding.
At least that is the idea. Have you spotted a bug, perhaps?
>> (shortlog since v1.4.4.3 here)
>
> I'd rather have description a la "what's cooking" here...
Send the summary to the list and I'll append it to the release
notes.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 10:24 ` Junio C Hamano
@ 2006-12-27 11:54 ` Johannes Schindelin
2006-12-27 12:15 ` Jakub Narebski
2006-12-27 12:12 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-27 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
Hi,
On Wed, 27 Dec 2006, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > I don't quite like it. Why if someone uses different encoding
> > that utf-8 because his terminal is not set to utf-8? Having suddenly
> > what looks like garbage on output, while input was in local encoding
> > (and specified in i18n.commitencoding) is a bit suprising...
>
> If Luben wants UTF-8 in his project, but somebody he pulled from was
> mistakenly used latin-1, then the commit pulled record latin-1 while
> Luben has i18n.commitencoding in his repository set to UTF-8. Output
> will be done in UTF-8 for Luben. For the originator of that latin-1
> commit, i18n.commitencoding says latin-1 (and that was the only reason
> he managed to create such a commit) and git show of that commit would
> not involve recoding.
I think that this is a misunderstanding. Maybe the config variable is
misnamed. As is clearly visible from the commit messages, this whole stuff
is meant to reencode to whatever encoding the caller of git-log likes, not
just UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding.
BTW I think that latin-1 is not a valid encoding name (at least in my
setup it isn't), so we should rather talk about iso-8859-1.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 10:24 ` Junio C Hamano
2006-12-27 11:54 ` Johannes Schindelin
@ 2006-12-27 12:12 ` Jakub Narebski
2006-12-27 13:00 ` Horst H. von Brand
` (2 more replies)
1 sibling, 3 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-27 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>>
>>> - The commits referred to by reflog entries are now protected
>>> against pruning. The new command "git reflog expire" can be
>>> used to truncate older reflog entries and entries that refer
>>> to commits that have been pruned away previously.
>>>
>>> Existing repositories that have been using reflog may get
>>> complaints from fsck-objects; please run "git reflog expire
>>> --all" first to remove reflog entries that refer to commits
>>> that are no longer in the repository before attempting to
>>> repack it.
>>
>> That's a bit bad, as it forces to lose some info... but that
>> info was not that useful anyway.
>
> I am tired of listening to this useless FUD of yours. You lost
> the information when you pruned away the underlying objects; you
> are not losing information when you expire the reflog entries
> that became useless long time ago.
Sorry, this is a bit of my inner packrat ;-) showing thru.
I'd rather use "git reflog expire --pruned" to remove reflog entries
which refer to commits which are no longer in the repository; I don't
know, perhaps "git reflog expire --all" does that: but there is no
Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
but 1.4.4.3). So most probably it is just the case of adding an alias
to reflog expire option.
>>> - A commit object recorded in non UTF-8 encoding records the
>>> encoding i18n.commitencoding specified in the originating
>>> repository in a new "encoding" header. This information is
>>> used by git-log and friends to reencode the message to UTF-8
>>> when displaying.
>>
>> I don't quite like it. Why if someone uses different encoding
>> that utf-8 because his terminal is not set to utf-8? Having suddenly
>> what looks like garbage on output, while input was in local encoding
>> (and specified in i18n.commitencoding) is a bit suprising...
>
> If Luben wants UTF-8 in his project, but somebody he pulled from
> was mistakenly used latin-1, then the commit pulled record
> latin-1 while Luben has i18n.commitencoding in his repository
> set to UTF-8. Output will be done in UTF-8 for Luben. For the
> originator of that latin-1 commit, i18n.commitencoding says
> latin-1 (and that was the only reason he managed to create such
> a commit) and git show of that commit would not involve
> recoding.
>
> At least that is the idea. Have you spotted a bug, perhaps?
Perhaps that is the idea, but that idea is not described in above
new feature announcement. "... to reencode the message to UTF-8
when displaying, if needed." would cover it, but perhaps better
would be to cover this in more detail: "reencode message to UTF-8
if i18n.commitencoding is not set to something other than UTF-8",
or "reencode ... to i18n.commitencoding ... if needed".
BTW. what happens for NO_ICONV? Just curious...
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 12:12 ` Jakub Narebski
@ 2006-12-27 13:00 ` Horst H. von Brand
2006-12-27 19:42 ` Junio C Hamano
2006-12-27 19:45 ` Junio C Hamano
2006-12-28 0:32 ` Jakub Narebski
2 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-27 13:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> Perhaps that is the idea, but that idea is not described in above
> new feature announcement. "... to reencode the message to UTF-8
> when displaying, if needed." would cover it, but perhaps better
> would be to cover this in more detail: "reencode message to UTF-8
> if i18n.commitencoding is not set to something other than UTF-8",
> or "reencode ... to i18n.commitencoding ... if needed".
And what happens to the people who can't/won't display UTF-8? This is a
both a project wide configuration (how does stuff get saved) + a user/local
configuration (how to display stuff).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 13:00 ` Horst H. von Brand
@ 2006-12-27 19:42 ` Junio C Hamano
2006-12-28 0:49 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 19:42 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Jakub Narebski, git
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>
>> Perhaps that is the idea, but that idea is not described in above
>> new feature announcement. "... to reencode the message to UTF-8
>> when displaying, if needed." would cover it, but perhaps better
>> would be to cover this in more detail: "reencode message to UTF-8
>> if i18n.commitencoding is not set to something other than UTF-8",
>> or "reencode ... to i18n.commitencoding ... if needed".
>
> And what happens to the people who can't/won't display UTF-8? This is a
> both a project wide configuration (how does stuff get saved) + a user/local
> configuration (how to display stuff).
Presumably you would do something like:
git log | tcs -f utf -t latin1 | less
The point being that the input to tcs will be uniformly UTF-8
even the committers used Latin-1 and UTF-8, either carelessly or
deliberately [*1*].
Maybe i18n.displayencoding set to latin1 is what you are after?
I think it might make sense...
In any case, as Jakub and others pointed out, the description
was not nice nor clear. How about this as an update?
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects. This will continue to be the
case. However, a non UTF-8 commit encoding _must_ be
explicitly set with i18n.commitencoding in the repository
where a commit is made; otherwise git-commit-tree will
complain if the log message does not look like a valid UTF-8
string.
[Side note: in v1.5.0 preview, it only warns about this
situation; I have a feeling that it might be better to promote
this to an error and refuse to commit until the user sets
i18n.commitencoding to the name of the legacy encoding used for
the project -- this will be a one-time inconvenience but will
be much better in the long run.]
- The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the encoding specified with
i18n.commitencoding when displaying, if they are different.
[Footnote]
*1* For encoding as simple as Latin I do not think it is an
issue, but we do not want to encode everything to UTF-8 at
commit time, because non-reversible conversion can lose
information. I do not want to rule out a situation where a
particular commit log entry needs to be in an encoding different
from the project norm, which hopefully is UTF-8, because it
needs to describe something in a character that cannot be
reversibly converted to UTF-8 (maybe the project is about iconv
enhancement, the commit fixes something related to irreversible
conversion and the log message wants to give an example).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 19:42 ` Junio C Hamano
@ 2006-12-28 0:49 ` Junio C Hamano
2006-12-28 1:44 ` Nicolas Pitre
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 0:49 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> ...
>> And what happens to the people who can't/won't display UTF-8? This is a
>> both a project wide configuration (how does stuff get saved) + a user/local
>> configuration (how to display stuff).
> ...
> Maybe i18n.displayencoding set to latin1 is what you are after?
> I think it might make sense...
I've done this and will be pushing the result out in 'next'
shortly, with a new test. I find the result mostly sensible.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-28 0:49 ` Junio C Hamano
@ 2006-12-28 1:44 ` Nicolas Pitre
2006-12-29 11:56 ` David Kågedal
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-12-28 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst H. von Brand, git
On Wed, 27 Dec 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> > ...
> >> And what happens to the people who can't/won't display UTF-8? This is a
> >> both a project wide configuration (how does stuff get saved) + a user/local
> >> configuration (how to display stuff).
> > ...
> > Maybe i18n.displayencoding set to latin1 is what you are after?
> > I think it might make sense...
>
> I've done this and will be pushing the result out in 'next'
> shortly, with a new test. I find the result mostly sensible.
Shouldn't the LANG environment variable be used for this purpose
instead?
Nicolas
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-28 1:44 ` Nicolas Pitre
@ 2006-12-29 11:56 ` David Kågedal
0 siblings, 0 replies; 601+ messages in thread
From: David Kågedal @ 2006-12-29 11:56 UTC (permalink / raw)
To: git
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 27 Dec 2006, Junio C Hamano wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> > "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>> > ...
>> >> And what happens to the people who can't/won't display UTF-8? This is a
>> >> both a project wide configuration (how does stuff get saved) + a user/local
>> >> configuration (how to display stuff).
>> > ...
>> > Maybe i18n.displayencoding set to latin1 is what you are after?
>> > I think it might make sense...
>>
>> I've done this and will be pushing the result out in 'next'
>> shortly, with a new test. I find the result mostly sensible.
>
> Shouldn't the LANG environment variable be used for this purpose
> instead?
You mean LC_CTYPE, no?
--
David Kågedal
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 12:12 ` Jakub Narebski
2006-12-27 13:00 ` Horst H. von Brand
@ 2006-12-27 19:45 ` Junio C Hamano
2006-12-28 0:32 ` Jakub Narebski
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 19:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> ... I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3)...
If that is the case, may I ask you to at least please make it a
habit to read what are relevant to the topic under discussion
before jumping in? The list traffic is already high enough that
I am spending a lot of time just to skim all the messages posted
here -- I think that time is better spent on development and
improvements.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 12:12 ` Jakub Narebski
2006-12-27 13:00 ` Horst H. von Brand
2006-12-27 19:45 ` Junio C Hamano
@ 2006-12-28 0:32 ` Jakub Narebski
2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-28 0:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
Jakub Narebski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Junio C Hamano wrote:
>>>>
>>>> - The commits referred to by reflog entries are now protected
>>>> against pruning. The new command "git reflog expire" can be
>>>> used to truncate older reflog entries and entries that refer
>>>> to commits that have been pruned away previously.
>>>>
>>>> Existing repositories that have been using reflog may get
>>>> complaints from fsck-objects; please run "git reflog expire
>>>> --all" first to remove reflog entries that refer to commits
>>>> that are no longer in the repository before attempting to
>>>> repack it.
[...]
> I'd rather use "git reflog expire --pruned" to remove reflog entries
> which refer to commits which are no longer in the repository; I don't
> know, perhaps "git reflog expire --all" does that: but there is no
> Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
> but 1.4.4.3). So most probably it is just the case of adding an alias
> to reflog expire option.
Thanks for adding Documentation/git-reflog.txt. Nevertheless it didn't
add the information that "git reflog expire" removes reflog entries that
refer to commits that are no longer in the repository (see attached patch).
I'm not sure if such technical information should be in git-reflog(1),
but does only second, current sha1 in reflog line matters for prune?
And does expiring rewrite reflog (previous sha1, making always previous
sha1 (first sha1 in reflog line) always to refer some commit in earlier
reflog line, or before first reflog line), or only delete lines?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
[-- Attachment #2: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries --]
[-- Type: text/plain, Size: 1327 bytes --]
>From c39e864dec5fc5542e9dd14235a48fa2bb77ed6a Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Thu, 28 Dec 2006 01:30:05 +0100
Subject: [PATCH] Add information in git-reflog(1) that "expire" removes pruned entries
Add information to Documentation/git-reflog.txt that "expire" subcommand
also removes entries which refer to commits that are no longer in
repository.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-reflog.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 55a24d3..04ea51a 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -22,11 +22,12 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
`expire-unreachable` time and are not reachable from the current
-tip, are removed from the reflog. This is typically not used
+tip, are removed from the reflog. Entries which refer to
+commits that are no longer in the repository are pruned
+regardless of their age. This command is typically not used
directly by the end users -- instead, see gitlink:git-gc[1].
-
OPTIONS
-------
--
1.4.4.3
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 10:12 ` Jakub Narebski
2006-12-27 10:24 ` Junio C Hamano
@ 2006-12-27 10:50 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 10:50 UTC (permalink / raw)
To: git; +Cc: jnareb
Jakub Narebski <jnareb@gmail.com> writes:
> Just a few comments:
>
>> - git-add without any argument does not add everything
>> anymore. Say "git add ." if you want to.
>
> Perhaps information that git-add can be used to add ignored files
> with -f option should be added? Or is it not important enough?
Thanks. Will change the above bullet to this:
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
2006-12-27 8:18 ` Shawn Pearce
2006-12-27 10:12 ` Jakub Narebski
@ 2006-12-27 12:06 ` Horst H. von Brand
2006-12-28 2:58 ` Junio C Hamano
2006-12-28 1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
2006-12-28 3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
4 siblings, 1 reply; 601+ messages in thread
From: Horst H. von Brand @ 2006-12-27 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
Could somebody please summarize how to "upgrade" a repository to the new
layout? This has got my head spinning... and I'm /not/ cloning the
various repos I've got here just to take advantage of the changes.
Thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 12:06 ` Horst H. von Brand
@ 2006-12-28 2:58 ` Junio C Hamano
2006-12-28 11:50 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 2:58 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> This is still rough, but I think we have a pretty good idea what
>> will and what won't be in v1.5.0 by now, and end-of-year is a
>> good slow time to summarize what we have done.
>
> Could somebody please summarize how to "upgrade" a repository to the new
> layout? This has got my head spinning... and I'm /not/ cloning the
> various repos I've got here just to take advantage of the changes.
The old layout was to map remote branch $B to local tracking
branch .git/refs/heads/$B, unless $B == 'master' in which case
it was mapped to .git/refs/heads/origin (and I think we
discarded 'origin' at remote).
Each remote branch $B is tracked with .git/refs/remote/origin/$B
in the new layout.
And you will get something like this in your .git/config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
The first section defines what the token 'origin' means when you
say "git pull origin" or "git fetch origin". remote.origin.url
defines the URL to fetch/pull from, and remote.origin.fetch
supplies the refspecs you omitted from the command line (fetch
everything from refs/heads/ hierarchy of remote and store them
in my refs/remotes/origin/ hierarchy).
The second section defines what happens when you say "git pull"
or "git fetch" while on your "master" branch. It tells that you
meant to say "git pull origin" or "git fetch origin" when you
omitted the URL argument from the command line. And because you
are also omitting the refspecs, remote.origin.fetch kicks in and
slurps all the branches from the remote side and stores them in
your refs/remotes/origin/ hierarchy. When the command was "git
pull", it also says the merge that follows the fetch is to merge
the 'master' branch at the remote side (which happens to be
copied to your remotes/origin/master only because you have
remote.origin.fetch) into your current branch (which is
"master", because this section is about what happens while you
are on your "master" branch).
So for an existing repository that does not use the separate
remotes layout, you can easily convert that by hand if you
wanted to by:
- Move tracking branches from refs/heads/* to
refs/remotes/origin/*,
- create the config section like the above in .git/config, and
- remove .git/remotes/origin when you are done.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-28 2:58 ` Junio C Hamano
@ 2006-12-28 11:50 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-12-28 11:50 UTC (permalink / raw)
To: git
[Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>,
"Horst H. von Brand" <vonbrand@inf.utfsm.cl>]
Junio C Hamano wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>>> This is still rough, but I think we have a pretty good idea what
>>> will and what won't be in v1.5.0 by now, and end-of-year is a
>>> good slow time to summarize what we have done.
>>
>> Could somebody please summarize how to "upgrade" a repository to the new
>> layout? This has got my head spinning... and I'm /not/ cloning the
>> various repos I've got here just to take advantage of the changes.
>
> The old layout was to map remote branch $B to local tracking
> branch .git/refs/heads/$B, unless $B == 'master' in which case
> it was mapped to .git/refs/heads/origin (and I think we
> discarded 'origin' at remote).
How to discard 'origin' in the new wildcard / globbing remote config?
IIRC there was proposal to use '-' or '!' to exclude branch from
fetching, but no code...
[...]
> - create the config section like the above in .git/config, and
You can use contrib/remotes2config.sh script...
> - remove .git/remotes/origin when you are done.
...which saves remotes/ under remotes.old/
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* An early draft of v1.5.0 release notes (2nd ed)
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
` (2 preceding siblings ...)
2006-12-27 12:06 ` Horst H. von Brand
@ 2006-12-28 1:45 ` Junio C Hamano
2006-12-28 2:03 ` Shawn Pearce
2007-01-10 7:58 ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
2006-12-28 3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
4 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 1:45 UTC (permalink / raw)
To: git
This incorporates comments from the list (thanks). Maybe I
should park this in 'todo' branch so that people can review the
updates more easily.
-- >8 --
Major changes that are not news
-------------------------------
There were a handful big changes that happened before this major
release.
This section is for people who are upgrading from ancient
versions. Some of them are one-way street upgrades -- once you
use the feature your repository cannot be used with ancient git.
- There is a new configuration variable core.legacyheaders that
changes the format of loose objects to more efficient to pack
and send out of the repository over git native protocol.
However, this format cannot be read by git older than v1.4.2;
people fetching from your repository using older clients over
dumb transports (e.g. http) will also be affected. This is
not enabled by default.
- Another configuration repack.usedeltabaseoffset further
allows packfile to be created in more space efficient format,
which cannot be read by git older than v1.4.3. This is not
enabled by default.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native client can fetch
from a repository that packed its tags, but older dumb
transports cannot. This is done by an explicit user action,
either by use of "git pack-refs --prune" command or by use of
"git gc" command.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timer users.
- 'git archive' superseded 'git tar' in v1.4.3;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is an v1.4.0 invention.
Updates in v1.5.0 since v1.4.4 series
-------------------------------------
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
- git-add tries to be more friendly to users by offering an
interactive mode.
- git-commit <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout and objects transfer
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones (the latter is still supported).
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
used to track branches from the origin. New branches that
appear on the origin side after a clone is made are also
tracked automatically.
- git-branch and git-show-branch know remote tracking branches.
- git-push can now be used to delete a remote branch or a tag.
This requires the updated git on the remote side.
- git-push more agressively keeps the transferred objects
packed. Earlier we recommended to monitor amount of loose
objects and repack regularly, but you should repack when you
accumulated too many small packs this way as well. Updated
git-count-objects helps you with this.
* Reflog
- Reflog records the history of where the tip of each branch
was at each moment. This facility is enabled by default for
repositories with working trees, and can be accessed with the
"branch@{time}" and "branch@{Nth}" notation.
- "git show-branch" learned showing the reflog data with the
new --reflog option.
- The commits referred to by reflog entries are now protected
against pruning. The new command "git reflog expire" can be
used to truncate older reflog entries and entries that refer
to commits that have been pruned away previously with older
versions of git.
Existing repositories that have been using reflog may get
complaints from fsck-objects; please run "git reflog expire
--all" first to remove reflog entries that refer to commits
that are no longer in the repository before attempting to
repack it.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
* Packed refs
- Repositories with hundreds of tags have been paying large
overhead, both in storage and in runtime. A new command,
git-pack-refs, can be used to "pack" them in more efficient
representation.
- Clones and fetches over dumb transports are now aware of
packed refs and can download from repositories that use
them.
* Configuration
- configuration related to colorize setting are consolidated
under color.* namespace (older diff.color.*, status.color.*
are still supported).
* Less external dependency
- We no longer require the "merge" program from the RCS suite.
All 3-way file-level merges are now done internally.
- The original implementation of git-merge-recursive which was
in Python has been removed; we have C implementation of it
now.
- git-shortlog is no longer a Perl script. It no longer
requires output piped from git-log; it can accept revision
parameters directly on the command line.
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects. This will continue to be the
case. However, a non UTF-8 commit encoding _must_ be
explicitly set with i18n.commitencoding in the repository
where a commit is made; otherwise git-commit-tree will
complain if the log message does not look like a valid UTF-8
string.
- The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the log output encoding when
displaying, if they are different. The log output encoding
is determined by "git log --encoding=<encoding>",
i18n.logoutputencoding configuration, or i18n.commitencoding
configuration, in the decreasing order of preference, and
defaults to UTF-8.
* User support
- Quite a lot of documentation updates.
- Bash completion scripts have been updated heavily.
- Better error messages for often used Porcelainish commands.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
@ 2006-12-28 2:03 ` Shawn Pearce
2006-12-28 2:20 ` Junio C Hamano
2007-01-10 7:58 ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
>
> -- >8 --
>
> Major changes that are not news
> -------------------------------
If these major changes aren't news, what are they? Chopped liver?
I'm highly confused by the section header.
--
Shawn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 2:03 ` Shawn Pearce
@ 2006-12-28 2:20 ` Junio C Hamano
2006-12-28 2:28 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 2:20 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>>
>> -- >8 --
>>
>> Major changes that are not news
>> -------------------------------
>
> If these major changes aren't news, what are they?
Exactly as described in the part you did not quote:
There were a handful big changes that happened before this major
release.
This section is for people who are upgrading from ancient
versions.
In other words, they are only to help people who were not paying
enough attention to earlier releases.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 2:20 ` Junio C Hamano
@ 2006-12-28 2:28 ` Shawn Pearce
2006-12-28 2:41 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28 2:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >>
> >> -- >8 --
> >>
> >> Major changes that are not news
> >> -------------------------------
> >
> > If these major changes aren't news, what are they?
>
> Exactly as described in the part you did not quote:
>
> There were a handful big changes that happened before this major
> release.
>
> This section is for people who are upgrading from ancient
> versions.
>
> In other words, they are only to help people who were not paying
> enough attention to earlier releases.
OK, yet again I don't quite quote enough. Or read enough. ;-)
But maybe you can title the section
Major changes since 1.2.x
? Or whatever version preceeded when we started to add that stuff?
The section is really for those who are upgrading from ancient
versions, but the title of the section implies (at least to me)
that these changes aren't something important.
Just my (nearly worthless against the Euro) two US pennies...
--
Shawn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 2:28 ` Shawn Pearce
@ 2006-12-28 2:41 ` Junio C Hamano
2006-12-28 2:47 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 2:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> The section is really for those who are upgrading from ancient
> versions, but the title of the section implies (at least to me)
> that these changes aren't something important.
True. How about "Something important you should already know
but just in case" ;-)?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 2:41 ` Junio C Hamano
@ 2006-12-28 2:47 ` Shawn Pearce
2006-12-28 5:54 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-12-28 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > The section is really for those who are upgrading from ancient
> > versions, but the title of the section implies (at least to me)
> > that these changes aren't something important.
>
> True. How about "Something important you should already know
> but just in case" ;-)?
Sure, that's more fun then my proposed text and does summarize the
section better. Plus it reminds Git users that maybe they should
track our releases a little bit more often than only on "major"
version number increments. :-)
--
Shawn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (2nd ed)
2006-12-28 2:47 ` Shawn Pearce
@ 2006-12-28 5:54 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-28 5:54 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>> > The section is really for those who are upgrading from ancient
>> > versions, but the title of the section implies (at least to me)
>> > that these changes aren't something important.
>>
>> True. How about "Something important you should already know
>> but just in case" ;-)?
>
> Sure, that's more fun then my proposed text and does summarize the
> section better. Plus it reminds Git users that maybe they should
> track our releases a little bit more often than only on "major"
> version number increments. :-)
That was a tongue-in-cheek comment.
I consider git is still young and I have the right to gripe at
the list if something that has been cooking in 'next' without
anybody complaining causes a real breakage immediately after it
gets pushed out to 'master'. But for the rest of the world, git
has already matured enough that there is much less need to be on
the bleeding edge for the lack of something crucial in the last
released version.
And let's face it. Nobody has enough time to keep track of the
changes to all tools he uses, it is not unusual to skip a
handful of minor versions, and it is a norm to get surprised
after an upgrade of any tool because there was a major change in
a couple of releases back that he skipped. I do not have the
right to complain if the end users do not follow every minor
release or every issue of "What's in git.git" messages. Not
anymore.
So I'd like the introductory section to have more positive
spin. I tried rewording it and pushed it out to 'todo' branch.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: An early draft of v1.5.0 release notes (3rd ed)
2006-12-28 1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
2006-12-28 2:03 ` Shawn Pearce
@ 2007-01-10 7:58 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2007-01-10 7:58 UTC (permalink / raw)
To: git
Instead of sending the full text, I'll send out the diff against
the one I sent out on the 27th last month.
Highlights:
* Introductory notes have been reworded heavily;
* I intend to merge bare repository support and detached HEAD
before v1.5.0, so a section each for them has been added;
* Sliding mmap and shallow clone are also mentioned.
The full text is available as v1.5.0.txt in 'todo' branch.
--
v1.5.0.txt | 180 +++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 149 insertions(+), 31 deletions(-)
diff --git a/v1.5.0.txt b/v1.5.0.txt
index 671c14b..9bbe825 100644
--- a/v1.5.0.txt
+++ b/v1.5.0.txt
@@ -1,37 +1,54 @@
-Major changes that are not news
--------------------------------
+GIT v1.5.0 Release Notes
+========================
-There were a handful big changes that happened before this major
-release.
+Old news
+--------
This section is for people who are upgrading from ancient
-versions. Some of them are one-way street upgrades -- once you
-use the feature your repository cannot be used with ancient git.
-
- - There is a new configuration variable core.legacyheaders that
- changes the format of loose objects to more efficient to pack
- and send out of the repository over git native protocol.
- However, this format cannot be read by git older than v1.4.2;
- people fetching from your repository using older clients over
- dumb transports (e.g. http) will also be affected. This is
- not enabled by default.
-
- - Another configuration repack.usedeltabaseoffset further
- allows packfile to be created in more space efficient format,
- which cannot be read by git older than v1.4.3. This is not
- enabled by default.
+versions of git. Although all of the changes in this section
+happened before the current v1.4.4 release, they are summarized
+here in the v1.5.0 release notes for people who skipped earlier
+versions.
+
+In general, you should not have to worry about incompatibility,
+and there is no need to perform "repository conversion" if you
+are updating to v1.5.0. However, some of the changes are
+one-way street upgrades; once you use them your repository
+can no longer be used with ancient git.
+
+ - There is a configuration variable core.legacyheaders that
+ changes the format of loose objects so that they are more
+ efficient to pack and to send out of the repository over git
+ native protocol, since v1.4.2. However, loose objects
+ written in the new format cannot be read by git older than
+ that version; people fetching from your repository using
+ older clients over dumb transports (e.g. http) using older
+ versions of git will also be affected.
+
+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows
+ packfile to be created in more space efficient format, which
+ cannot be read by git older than that version.
+
+The above two are not enabled by default and you explicitly have
+to ask for them, because these two features make repositories
+unreadable by older versions of git, and in v1.5.0 we still do
+not enable them by default for the same reason. We will change
+this default probably 1 year after 1.4.2's release, when it is
+reasonable to expect everybody to have new enough version of
+git.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
- 'one-file-per-tag' format. Older git-native client can fetch
- from a repository that packed its tags, but older dumb
- transports cannot. This is done by an explicit user action,
- either by use of "git pack-refs --prune" command or by use of
- "git gc" command.
+ 'one-file-per-tag' format. Older git-native clients can
+ still fetch from a repository that packed and pruned refs
+ (the server side needs to run the up-to-date version of git),
+ but older dumb transports cannot. Packing of refs is done by
+ an explicit user action, either by use of "git pack-refs
+ --prune" command or by use of "git gc" command.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
- this may surprise old timer users.
+ this may surprise old timers.
- 'git archive' superseded 'git tar' in v1.4.3;
@@ -43,7 +60,10 @@ use the feature your repository cannot be used with ancient git.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- - reflog is an v1.4.0 invention.
+ - reflog is an v1.4.0 invention. This allows you to name a
+ revision that a branch used to be at (e.g. "git diff
+ master@{yesterday} master" allows you to see changes since
+ yesterday's tip of the branch).
Updates in v1.5.0 since v1.4.4 series
@@ -80,7 +100,9 @@ Updates in v1.5.0 since v1.4.4 series
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
- created clones (the latter is still supported).
+ created clones. The latter is still supported and there is
+ no need to convert your existing repository if you are
+ already comfortable with your workflow with the layout.
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
@@ -100,6 +122,26 @@ Updates in v1.5.0 since v1.4.4 series
accumulated too many small packs this way as well. Updated
git-count-objects helps you with this.
+ - A new command, git-remote, can help you manage your remote
+ tracking branch definitions.
+
+
+* Bare repositories
+
+ - Certain commands change their behaviour in a bare repository
+ (i.e. a repository without associated working tree). We use
+ a fairly conservative heuristic (if $GIT_DIR is ".git", or
+ ends with "/.git", the repository is not bare) to decide if a
+ repository is bare, but "core.bare" configuration variable
+ can be used to override the heuristic when it misidentifies
+ your repository.
+
+ - git-fetch used to complain updating the current branch but
+ this is now allowed for a bare repository.
+
+ - NEEDSWORK: We should disable Porcelain-ish commands that
+ require a working tree in a bare repository.
+
* Reflog
@@ -118,15 +160,42 @@ Updates in v1.5.0 since v1.4.4 series
versions of git.
Existing repositories that have been using reflog may get
- complaints from fsck-objects; please run "git reflog expire
- --all" first to remove reflog entries that refer to commits
- that are no longer in the repository before attempting to
- repack it.
+ complaints from fsck-objects and may not be able to run
+ git-repack; please run "git reflog expire --all" first to
+ remove reflog entries that refer to commits that are no
+ longer in the repository when that happens.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
+* Detached HEAD
+
+ - You can give non-branch to "git checkout" now. This will
+ dissociate your HEAD from any of your branches. A typical
+ use of this feature is to "look around". E.g.
+
+ $ git checkout v2.6.16
+ ... compile, test, etc.
+ $ git checkout v2.6.17
+ ... compile, test, etc.
+
+ - After detaching your HEAD, you can go back to an existing
+ branch with usual "git checkout $branch". Also you can
+ start a new branch using "git checkout -b $newbranch".
+
+ - You can even pull from other repositories, make merges and
+ commits while your HEAD is detached. Also you can use "git
+ reset" to jump to arbitrary commit.
+
+ Going back to undetached state by "git checkout $branch" can
+ lose the current stat you arrived in these ways, and "git
+ checkout" refuses when the detached HEAD is not pointed by
+ any existing ref (an existing branch, a remote tracking
+ branch or a tag). This safety can be overriden with "git
+ checout -f".
+
+
* Packed refs
- Repositories with hundreds of tags have been paying large
@@ -181,6 +250,24 @@ Updates in v1.5.0 since v1.4.4 series
configuration, in the decreasing order of preference, and
defaults to UTF-8.
+ - Tools for e-mailed patch application now default to -u
+ behaviour; i.e. it always re-codes from the e-mailed encoding
+ to the encoding specified with i18n.commitencoding. This
+ unfortunately forces projects that have happily using a
+ legacy encoding without setting i18n.commitencoding, but
+ taken with other improvement, please excuse us for this very
+ minor one-time inconvenience.
+
+
+* Foreign SCM interfaces
+
+ - git-svn now requires the Perl SVN:: libraries, the
+ command-line backend was too slow and limited.
+
+ - the 'commit' subcommand of git-svn has been renamed to
+ 'set-tree', and 'dcommit' is the recommended replacement for
+ day-to-day work.
+
* User support
@@ -191,4 +278,35 @@ Updates in v1.5.0 since v1.4.4 series
- Better error messages for often used Porcelainish commands.
+* Sliding mmap
+
+ - We used to assume that we can mmap the whole packfile while
+ in use, but with a large project this consumes huge virtual
+ memory space and truly huge ones would not fit in the
+ userland address space on 32-bit platforms. We now mmap huge
+ packfile in pieces to avoid this problem.
+
+
+* Shallow clones
+
+ - There is a partial support for 'shallow' repositories that
+ keeps only recent history now. A 'shallow clone' is created
+ by specifying how deep that truncated history should be.
+
+ Currently a shallow repository has number of limitations:
+
+ - Cloning and fetching _from_ a shallow clone are not
+ supported (nor tested -- so they might work by accident but
+ they are not expected to).
+
+ - Pushing from nor into a shallow clone are not expected to
+ work.
+
+ - Merging inside a shallow repository would work as long as a
+ merge base is found in the recent history, but otherwise it
+ will be like merging unrelated histories and may result in
+ huge conflicts.
+ but this would be more than adequate for people who want to
+ look at near the tip of a big project with a deep history and
+ send patches in e-mail format.
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [RFH] An early draft of v1.5.0 release notes
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
` (3 preceding siblings ...)
2006-12-28 1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
@ 2006-12-28 3:03 ` Eric Wong
2006-12-28 5:34 ` Junio C Hamano
4 siblings, 1 reply; 601+ messages in thread
From: Eric Wong @ 2006-12-28 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> ancient versions such as v1.1.6 or v1.2.0, and there are a
> handful "one-way-street upgrades" and quite a few user visible
> changes that already have happened before v1.4.4. Namely:
Addendum:
git-svn related changes:
- git-svn now requires the Perl SVN:: libraries, the
command-line backend was too slow and limited.
- the 'commit' command has been renamed to 'set-tree', and
'dcommit' is the recommended replacement for day-to-day
work.
--
Eric Wong
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable) and announcing GIT 1.5.0 preview
@ 2006-12-26 3:22 Junio C Hamano
2006-12-29 5:44 ` What's in git.git (stable) Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-26 3:22 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT v1.5.0 preview
This is not yet -rc1 where all new topics close, but I think it
is getting pretty closer. I'd still want to merge updates to
fsck/prune to honor reflog entries before -rc1.
I think there are quite a lot of documentation updates remaining
after that. There is no patch for "fixed HEAD" yet, and while I
would not object people to try to get it working in time, it is
purely a feature enhancement and does not have backward
compatibility issues, so it does not have to block v1.5.0; it
can wait for later releases. So is sliding mmap().
* The 'master' branch has these since the last announcement.
Alexandre Julliard (1):
vc-git: Ignore errors caused by a non-existent directory
in vc-git-registered.
Brian Gernhardt (2):
Keep "git --git-dir" from causing a bus error.
Make git-show-branch options similar to git-branch.
Eric Wong (3):
Remove NO_ACCURATE_DIFF options from build systems
git-svn: enable common fetch/commit options for dcommit
Makefile: add quick-install-doc for installing pre-built manpages
Johannes Schindelin (4):
move read_mmfile() into xdiff-interface
Add a test for git-rerere
Make git-rerere a builtin
commit-tree: encourage UTF-8 commit messages.
Junio C Hamano (19):
git-add --interactive
git-add --interactive: hunk splitting
revision: --skip=<n>
merge and reset: adjust for "reset --hard" messages
default pull: forget about "newbie protection" for now.
Do not support "partial URL shorthand" anymore.
Really fix headers for __FreeBSD__
git-tag: lose exit after die
Allow branch.*.merge to talk about remote tracking branches.
git-add --interactive: add documentation
match_pathspec() -- return how well the spec matched
git-rm: update to saner semantics
t3600: update the test for updated git rm
git-rm: Documentation
read_directory: show_both option.
git-add: add ignored files when asked explicitly.
git-add: warn when adding an ignored file with an explicit request.
git-add -f: allow adding otherwise ignored files.
GIT v1.5.0 preview
Nicolas Pitre (1):
checkout: make the message about the need for a new branch a bit clearer
Robert Fitzsimons (16):
gitweb: Add missing show '...' links change.
gitweb: optimize git_get_last_activity.
gitweb: optimize git_shortlog_body.
gitweb: optimize git_summary.
gitweb: Use rev-list pattern search options.
gitweb: Require a minimum of two character for the search text.
gitweb: Allow search to be disabled from the config file.
gitweb: Paginate commit/author/committer search output
gitweb: Add parse_commits, used to bulk load commit objects.
gitweb: We do longer need the --parents flag in rev-list.
gitweb: Change summary, shortlog actions to use parse_commits.
gitweb: Change log action to use parse_commits.
gitweb: Change header search action to use parse_commits.
gitweb: Change atom, rss actions to use parse_commits.
gitweb: Change history action to use parse_commits.
gitweb: Use rev-list --skip option.
Shawn Pearce (4):
Use extended SHA1 syntax in merge-recursive conflicts.
Display 'theirs' branch name when possible in merge.
Rename gitfakemmap to git_mmap.
Switch git_mmap to use pread.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
2006-12-26 3:22 What's in git.git (stable) and announcing GIT 1.5.0 preview Junio C Hamano
@ 2006-12-29 5:44 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-29 5:44 UTC (permalink / raw)
To: git
I've merged a handful topics since v1.5.0-rc0.
- reflog is now integral part of the data tracked by git, as
far as local repository is concerned. You do not have to end
your sentence with "... but only if you haven't pruned" when
you tell your users "don't worry, you can get it back with
master@{2.hours.ago}" anymore.
- a single command "git gc" would help your repository
housekeeping chores.
- shallow-clone capable upload-pack/fetch-pack pair is in.
Although I think the way they cauterize the ancestry graph
during the want-have exchange is basically sound, I haven't
used it extensively and suspect not many people have. The
additional code, however, does not seem to harm the normal,
non-shallow operation in any way; this is to give them wider
exposure.
- recording the commit encoding in the new "encoding" header
and using it together with i18n.{logoutput,commit}encoding
upon output is also in. I think Nico's suggestion to use
LANG also makes sense (perhaps with LC_CTYPE), but haven't
done that myself yet.
- git-svn got a handful improvements.
- segfaulting bug in xdl_merge was fixed.
I'm waiting for ack's to my workaround for http-fetch breakage
when built with cURL 7.16.0, which I would like to resolve
before v1.5.0-rc1. Also I have a reproducible problem which I
suspect is with Shawn's sliding mmap(), and am hoping we can
ship the sliding mmap() as part of the v1.5.0 after resolving
it.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alexandre Julliard (6):
Shallow clone: do not ignore shallowness when following tags
fetch-pack: Properly remove the shallow file when it becomes empty.
upload-pack: Check for NOT_SHALLOW flag before sending a shallow to
the client.
git-fetch: Reset shallow_depth before auto-following tags.
get_shallow_commits: Avoid memory leak if a commit has been reached
already.
fetch-pack: Do not fetch tags for shallow clones.
Andy Parkins (1):
hooks/commit-msg: add example to add Signed-off-by line to message
Eric Wong (9):
git-svn: quiet down tests and fix some unportable shell constructs
git-svn: dcommit should diff against the current HEAD after committing
t6024-recursive-merge: quiet down this test
test-lib: quiet down init-db output for tests
t9200-git-cvsexportcommit.sh: quiet down commit
git-svn: remove non-delta fetch code paths
git-svn: print out the SVN library version in --version, too
git-svn: verify_ref() should actually --verify
git-svn: sort multi-init output
Jakub Narebski (2):
gitweb: Add mod_perl version string to "generator" meta header
gitweb: Precompile CGI routines for mod_perl
Jim Meyering (1):
update hook: redirect _both_ diagnostic lines to stderr upon tag failure
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
xdl_merge(): fix a segmentation fault when refining conflicts
Junio C Hamano (32):
We should make sure that the protocol is still extensible.
Why does it mean we do not have to register shallow if we have one?
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
shallow clone: unparse and reparse an unshallowed commit
add for_each_reflog_ent() iterator
Protect commits recorded in reflog from pruning.
Teach git-repack to preserve objects referred to by reflog entries.
reflog: fix warning message.
Move in_merge_bases() to commit.c
git reflog expire
reflog expire: prune commits that are not incomplete
reflog expire: do not punt on tags that point at non commits.
show-branch --reflog: add documentation.
Document --numstat in git-apply and git-diff
Document git-reset <commit> -- <paths>...
Move encoding conversion routine out of mailinfo to utf8.c
i18n.logToUTF8: convert commit log message to UTF-8
Teach log family --encoding
everyday: update for v1.5.0
count-objects -v: show number of packs as well.
rerere gc: honor configuration and document it
git-reflog: gc.* configuration and documentation.
everyday: replace a few 'prune' and 'repack' with 'gc'
Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc
Set NO_MMAP for Cygwin by default
UTF-8: introduce i18n.logoutputencoding.
gcc does not necessarily pass runtime libpath with -R
Rename t3900 test vector file
t3900: test conversion to non UTF-8 as well
GIT_SKIP_TESTS: allow users to omit tests that are known to break
core.logallrefupdates: log remotes/ tracking branches.
Allow non-fast-forward of remote tracking branches in default clone
Nicolas Pitre (3):
add .mailmap for git-shortlog output with the git repository
Add git-reflog to .gitignore
move git-blame to its place in .gitignore
Quy Tonthat (1):
git-send-email: default value for "From:" field.
Robert Fitzsimons (1):
gitweb: Re-enable rev-list --parents for parse_commit.
Shawn O. Pearce (8):
Don't crash during repack of a reflog with pruned commits.
Create 'git gc' to perform common maintenance operations.
Use GIT_REFLOG_ACTION environment variable instead.
Honor GIT_REFLOG_ACTION in git-rebase.
Use branch names in 'git-rebase -m' conflict hunks.
Ensure `git-pull` fails if `git-merge` fails.
Honor pull.{twohead,octopus} in git-merge.
Allow git-merge to select the default strategy.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2006-12-22 9:25 Junio C Hamano
2006-12-22 17:15 ` Randal L. Schwartz
2006-12-22 20:21 ` Quy Tonthat
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 9:25 UTC (permalink / raw)
To: git
I guess I'll need to push another maintenance release out soon,
if only to fix the manual pages.
On the 'master' front there are a handful more topics pushed out
from 'next'. I still need to apply the __FREEBSD__ fix yet, but
otherwise we should be able to start calming things down.
* The 'maint' branch has these fixes since the last announcement.
Johannes Schindelin (1):
diff --check: fix off by one error
Junio C Hamano (1):
spurious .sp in manpages
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: convert to using Git.pm
git-svn: remove support for the svn command-line client
git-svn: rename 'commit' command to 'set-tree'
Johannes Schindelin (5):
Introduce GIT_TEMPLATE_DIR
diff --check: fix off by one error
Use git-merge-file in git-merge-one-file, too
git-tag: support -F <file> option
git-reset --hard: tell the user what the HEAD was reset to
Josef Weidendorfer (1):
Move "no merge candidate" warning into git-pull
Junio C Hamano (22):
git-clone: use wildcard specification for tracking branches
git-pull: refuse default merge without branch.*.merge
git-clone: lose the artificial "first" fetch refspec
git-clone: lose the traditional 'no-separate-remote' layout
rev-list --left-right
Teach all of log family --left-right output.
Make left-right automatic.
fix testsuite: make sure they use templates freshly built from the source
Teach git-branch to delete tracking branches with -r -d
blame: -b (blame.blankboundary) and --root (blame.showroot)
Revert "fix testsuite: make sure they use templates freshly
built from the source"
Do not create $GIT_DIR/remotes/ directory anymore.
Use preprocessor constants for environment variable names.
Revert "Make left-right automatic."
git-add: error out when given no arguments.
spurious .sp in manpages
compat/inet_ntop: do not use u_int
diff documentation: mostly talk about <commit>
Revert "git-pull: refuse default merge without branch.*.merge"
parse-remote: mark all refs not for merge only when fetching more
than one
_XOPEN_SOURCE problem also exists on FreeBSD
commit-tree: do not overflow MAXPARENT
Quy Tonthat (2):
git-branch -d: do not stop at the first failure.
Documentation/git-branch: new -r to delete remote-tracking branches.
Shawn Pearce (3):
Suggest 'add' in am/revert/cherry-pick.
Rename imap-send's internal info/warn functions.
Introduce a global level warn() function.
Terje Sten Bjerkseth (1):
Fix system header problems on Mac OS X
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 9:25 Junio C Hamano
@ 2006-12-22 17:15 ` Randal L. Schwartz
2006-12-22 17:19 ` Randal L. Schwartz
2006-12-22 20:21 ` Quy Tonthat
1 sibling, 1 reply; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> git-pull: refuse default merge without branch.*.merge
Argh. How do I get back the old behavior?
"git-pull origin" doesn't seem to be enough.
You just broke a bunch of automated scripts for me.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 17:15 ` Randal L. Schwartz
@ 2006-12-22 17:19 ` Randal L. Schwartz
2006-12-22 18:09 ` Johannes Schindelin
2006-12-22 18:58 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 17:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> git-pull: refuse default merge without branch.*.merge
Randal> Argh. How do I get back the old behavior?
Randal> "git-pull origin" doesn't seem to be enough.
Randal> You just broke a bunch of automated scripts for me.
Ahh, it's "git-pull . origin".
Maybe a bit more warning for non-upward-compatible changes though, please.
Or maybe we should presume everything is non-upward compatible? I didn't
think a naked "git-pull" was that out of the ordinary.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 17:19 ` Randal L. Schwartz
@ 2006-12-22 18:09 ` Johannes Schindelin
2006-12-22 18:12 ` Randal L. Schwartz
2006-12-22 18:58 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 18:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
Hi,
On Fri, 22 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh. How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
Maybe "git-pull origin master"?
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
This is just a merge, not a real pull (it leaves out the fetch part).
> Maybe a bit more warning for non-upward-compatible changes though,
> please.
It is unfortunate that this change broke your scripts. But I really think
that the new behaviour is much saner: If you have different branches, you
probably do not want to pull the _same_ remote branch into _all_ of them.
So, for each branch (e.g. "xyz") for which you have a preferred upstream
(e.g. remote "linus" with branch "master"), say
$ git repo-config branch.xyz.remote linus
$ git repo-config branch.xyz.merge refs/heads/master
Then,
$ git pull
pulls your preferred upstream. But when you pull from another remote, or
into another branch, without specifying which remote branch you want to
pull, git now refuses to blindly pull branch "master". This should prevent
quite some pilot errors.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 18:09 ` Johannes Schindelin
@ 2006-12-22 18:12 ` Randal L. Schwartz
2006-12-22 18:21 ` Randal L. Schwartz
2006-12-22 19:21 ` Johannes Schindelin
0 siblings, 2 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 18:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Ahh, it's "git-pull . origin".
Johannes> This is just a merge, not a real pull (it leaves out the fetch part).
OK, so what does what a naked "git-pull" used to do before, which was
"fetch origin, then pull it into the current branch"?
Johannes> So, for each branch (e.g. "xyz") for which you have a preferred upstream
Johannes> (e.g. remote "linus" with branch "master"), say
Johannes> $ git repo-config branch.xyz.remote linus
Johannes> $ git repo-config branch.xyz.merge refs/heads/master
But that's not upward compatible. The default should be the old behavior,
or we need a better way to notify people that this breaks things.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 18:12 ` Randal L. Schwartz
@ 2006-12-22 18:21 ` Randal L. Schwartz
2006-12-22 19:21 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Randal L. Schwartz @ 2006-12-22 18:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> But that's not upward compatible. The default should be the old behavior,
Randal> or we need a better way to notify people that this breaks things.
Not to mention that the manpage still says:
git pull, git pull origin
Fetch the default head from the repository you cloned from and
merge it into your current branch.
So even if I was *looking* for a change in behavior, it wasn't documented.
Nothing changed in that area in recent history.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 18:12 ` Randal L. Schwartz
2006-12-22 18:21 ` Randal L. Schwartz
@ 2006-12-22 19:21 ` Johannes Schindelin
2006-12-22 20:13 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 19:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
Hi,
On Fri, 22 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >>>>> writes:
>
> >> Ahh, it's "git-pull . origin".
>
> Johannes> This is just a merge, not a real pull (it leaves out the fetch
> Johannes> part).
>
> OK, so what does what a naked "git-pull" used to do before, which was
> "fetch origin, then pull it into the current branch"?
$ git repo-config branch.xyz.remote origin
$ git repo-config branch.xyz.merge refs/heads/<whateveryourfirstfetchis>
> Johannes> So, for each branch (e.g. "xyz") for which you have a
> Johannes> preferred upstream (e.g. remote "linus" with branch
> Johannes> "master"), say
>
> Johannes> $ git repo-config branch.xyz.remote linus
> Johannes> $ git repo-config branch.xyz.merge refs/heads/master
>
> But that's not upward compatible. The default should be the old
> behavior, or we need a better way to notify people that this breaks
> things.
AFAIK it is not in maint. Not even in 1.4.4.3. So, you got it with master.
So, TFA should have been in a message "What's in git (stable)".
Alas, the commit a71fb0a1: "git-pull: refuse default merge without
branch.*.merge" was merged _after_ the latest announcement.
HOWEVER, it has been in "What's cooking in git (topics)".
Having said that, we could (at least for some time) print a big red
warning for the specific case of "git pull" meaning "git pull origin
<whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
Of course, you would not see it. Only your script.
BTW I would _never_ allow a script to rely on such a DWIM feature.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 19:21 ` Johannes Schindelin
@ 2006-12-22 20:13 ` Junio C Hamano
2006-12-22 20:44 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 20:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Randal L. Schwartz
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> HOWEVER, it has been in "What's cooking in git (topics)".
>
> Having said that, we could (at least for some time) print a big red
> warning for the specific case of "git pull" meaning "git pull origin
> <whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
>
> Of course, you would not see it. Only your script.
>
> BTW I would _never_ allow a script to rely on such a DWIM feature.
That's too strong a statement. It is not DWIM but has been a
longstanding rule to use "the first set of branches" for the
merge. We've merged the first set of branches since day one,
and even after branch.*.merge we've done so unless you do not
have such configuration.
The complaint (or "newbie protection") was a backward
incompatible change, and it was executed poorly. So my
apologies go to Merlyn.
While many "new features" can be done in backward compatible
way, any "newbie protection" can break existing practices --
because the whole point of "protection" is to forbid what once
was allowed only because we did not use to check. And when we
have something that we check now that we did not check before,
that by definition will not be backward compatible.
Some backward incompatibilities are more justfiable than others.
For example, we recently changed "git add" without argument not
to do anything. It used to have the same effect as "git add .",
but (1) adding all files in a working tree is a rare event, (2)
just a single dot is not hard to type, (3) without argument you
will get a response "not doing anything". On the other hand,
doing "git add" without argument by mistake and ending up with
the index with many unwanted files is more painful and more
likely to hapen -- it is more valuable to protect users against
it than saving the two keysrokes. That's why I think that
change is a justified improvement.
I do not think this "merge complaint", at least in the form that
lived on 'master', is justifiable. The first one that was
merged from the topic made it a requirement to have the
branch.*.merge configuration when you do not give explicit
refspecs on the command line, which was just outright WRONG.
The one currently on the public repository says if the fetch
ended up getting only one branch then not having branch.*.merge
is Ok, which arguably is an improvement, but I do not think is
good enough. I mentioned other possibilities in my earlier
message.
I also personally think that it is not as clear cut as the "git
add" case that "the first set of branches" rule is wrong, but
the trouble I caused to Merlyn and Luben primarily comes from
the check to trigger "newbie protection", not from what the
protection is trying to do.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 20:13 ` Junio C Hamano
@ 2006-12-22 20:44 ` Johannes Schindelin
2006-12-22 21:44 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-22 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz
Hi,
On Fri, 22 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > HOWEVER, it has been in "What's cooking in git (topics)".
> >
> > Having said that, we could (at least for some time) print a big red
> > warning for the specific case of "git pull" meaning "git pull origin
> > <whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
> >
> > Of course, you would not see it. Only your script.
> >
> > BTW I would _never_ allow a script to rely on such a DWIM feature.
>
> That's too strong a statement. It is not DWIM but has been a
> longstanding rule to use "the first set of branches" for the
> merge. We've merged the first set of branches since day one,
> and even after branch.*.merge we've done so unless you do not
> have such configuration.
Okay, I have been wrong. My sincere apologies.
So, if I understand your option (2) correctly, it complains _only_ if
there is at least one branch.*.merge in the config, but not for the
current branch?
I think that would safeguard the existing repositories _and_ the new ones,
because git-clone sets them up with such an entry to begin with.
If that behaviour was meant by (2), I am all for it.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 20:44 ` Johannes Schindelin
@ 2006-12-22 21:44 ` Junio C Hamano
2006-12-26 20:25 ` Luben Tuikov
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 21:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Randal L. Schwartz, Josef Weidendorfer, Luben Tuikov
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So, if I understand your option (2) correctly, it complains _only_ if
> there is at least one branch.*.merge in the config, but not for the
> current branch?
>
> I think that would safeguard the existing repositories _and_ the new ones,
> because git-clone sets them up with such an entry to begin with.
>
> If that behaviour was meant by (2), I am all for it.
I am not quite sure about that. An old timer would work in a
newly cloned repository after all, and what this "newbie
protection" is breaking is not existing repositories but
expectation from existing users.
In any case, here is a patch for discussion.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f163821..b4d071b 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
merge_branches=$(git-repo-config \
--get-all "branch.${curr_branch}.merge")
fi
- # If we are fetching only one branch, then first branch
- # is the only thing that makes sense to merge anyway,
- # so there is no point refusing that traditional rule.
- if test $# != 1 && test "z$merge_branches" = z
+ if test "z$merge_branches" = z &&
+ # If we are fetching only one branch, then
+ # first branch is the only thing that makes
+ # sense to merge anyway, so there is no point
+ # refusing that traditional rule.
+ test $# != 1 &&
+
+ # Also, old timers have been happily working
+ # with the first branch rule without having
+ # any branch.*.merge configuration, so if
+ # there is none, do not bother with this
+ # "newbie protection". A newly cloned
+ # repository would have branch.master.merge
+ # set for it.
+ git repo-config --get-regexp \
+ '^branch\..*\.merge$' >/dev/null
then
merge_branches=..this..would..never..match..
fi
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 21:44 ` Junio C Hamano
@ 2006-12-26 20:25 ` Luben Tuikov
2006-12-26 23:54 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Luben Tuikov @ 2006-12-26 20:25 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: git, Randal L. Schwartz, Josef Weidendorfer
--- Junio C Hamano <junkio@cox.net> wrote:
> I am not quite sure about that. An old timer would work in a
> newly cloned repository after all, and what this "newbie
> protection" is breaking is not existing repositories but
> expectation from existing users.
Hmm, "newbie protection" doesn't sound good. It sounds like
"screw the old-timers and let's change well-established workflow".
The expectation is that one always pulls into origin, merges
into master, and maybe checks out master to see the remote
master. From then on, they decide what, where and how to
merge (from) master into any local branches, and then
eventually export local branches to the public.
The "^branch.\.*" options seem to be counter-intuitive to
1) git's behavor and 2) see above.
Generally "pulling" a remote master in a local branch, without
the local "origin+master" being fast-forwarded/merged should be
considered non-git-conformant behavior. Assuming that the local
branch is a branch of master/origin, which is almost ever the case.
> In any case, here is a patch for discussion.
>
> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index f163821..b4d071b 100755
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
> merge_branches=$(git-repo-config \
> --get-all "branch.${curr_branch}.merge")
> fi
> - # If we are fetching only one branch, then first branch
> - # is the only thing that makes sense to merge anyway,
> - # so there is no point refusing that traditional rule.
> - if test $# != 1 && test "z$merge_branches" = z
> + if test "z$merge_branches" = z &&
> + # If we are fetching only one branch, then
> + # first branch is the only thing that makes
> + # sense to merge anyway, so there is no point
> + # refusing that traditional rule.
> + test $# != 1 &&
> +
> + # Also, old timers have been happily working
> + # with the first branch rule without having
> + # any branch.*.merge configuration, so if
> + # there is none, do not bother with this
> + # "newbie protection". A newly cloned
> + # repository would have branch.master.merge
> + # set for it.
It should probably have branch.*.remote _and_ branch.*.merge set
for completeness. Or we should remove the branch.* options
from git-config and leave this up to porcelains.
> + git repo-config --get-regexp \
> + '^branch\..*\.merge$' >/dev/null
How does this "set" it?
Luben
> then
> merge_branches=..this..would..never..match..
> fi
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-26 20:25 ` Luben Tuikov
@ 2006-12-26 23:54 ` Junio C Hamano
2006-12-27 1:19 ` Luben Tuikov
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-26 23:54 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
Luben Tuikov <ltuikov@yahoo.com> writes:
>> I am not quite sure about that. An old timer would work in a
>> newly cloned repository after all, and what this "newbie
>> protection" is breaking is not existing repositories but
>> expectation from existing users.
>
> Hmm, "newbie protection" doesn't sound good. It sounds like
> "screw the old-timers and let's change well-established workflow".
As far as I am concerned, this is a topic already closed four
days ago with commit fb8696d9.
Are you way too behind, are you rubbing it in, or am I
hallucinating and fb8696d9 did not actually fix it?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-26 23:54 ` Junio C Hamano
@ 2006-12-27 1:19 ` Luben Tuikov
2006-12-27 2:14 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Luben Tuikov @ 2006-12-27 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> >> I am not quite sure about that. An old timer would work in a
> >> newly cloned repository after all, and what this "newbie
> >> protection" is breaking is not existing repositories but
> >> expectation from existing users.
> >
> > Hmm, "newbie protection" doesn't sound good. It sounds like
> > "screw the old-timers and let's change well-established workflow".
>
> As far as I am concerned, this is a topic already closed four
> days ago with commit fb8696d9.
>
> Are you way too behind, are you rubbing it in, or am I
> hallucinating and fb8696d9 did not actually fix it?
I'm behind. I'll pull and take a look at that commit.
Luben
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-27 1:19 ` Luben Tuikov
@ 2006-12-27 2:14 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-27 2:14 UTC (permalink / raw)
To: ltuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>> >> I am not quite sure about that. An old timer would work in a
>> >> newly cloned repository after all, and what this "newbie
>> >> protection" is breaking is not existing repositories but
>> >> expectation from existing users.
>> >
>> > Hmm, "newbie protection" doesn't sound good. It sounds like
>> > "screw the old-timers and let's change well-established workflow".
>>
>> As far as I am concerned, this is a topic already closed four
>> days ago with commit fb8696d9.
>>
>> Are you way too behind, are you rubbing it in, or am I
>> hallucinating and fb8696d9 did not actually fix it?
>
> I'm behind. I'll pull and take a look at that commit.
Thanks.
And sorry that I sounded harsher than necessary. Between the
two paragraphs, I meant to say "... with commit fb8696d9. It
was a mistake, I broke existing workflows, I apologized, and the
commit should have fixed it".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 17:19 ` Randal L. Schwartz
2006-12-22 18:09 ` Johannes Schindelin
@ 2006-12-22 18:58 ` Junio C Hamano
2006-12-22 20:04 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 18:58 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh. How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
>
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
>
> Maybe a bit more warning for non-upward-compatible changes though, please.
>
> Or maybe we should presume everything is non-upward compatible? I didn't
> think a naked "git-pull" was that out of the ordinary.
Things are supposed to be upward compatible, but this round
until v1.5.0 some things may not be when it is justifiably an
improvement. For example, we've already made 'separate remote'
not only the default but the only layout 'git clone' produces.
I cannot think of others offhand, but I am reasonably certain
there are others. We need a "incompatible changes" list.
The tradtional "pull always merges the first set of branches"
rule, although I was actually very much in favor of it, was
something that was hated by everybody.
It was said that people had lot of trouble after doing "git pull
origin" without any refspecs ("git pull" without any argument
defaults to 'origin' which is backward compatible, if you do not
have branch.*.remote, so that form has the same issues), when on
a branch other than the 'master' branch. "merges the same first
set of branches no matter which branch you are on" was the rule,
but people did not want to merge the ones they usually merge to
their 'master' but wanted some other branch merged.
"branch.*.merge" can be used to specify this, but if you do not
have need for this "merge different branches depending on which
branch I am on", you do not have to use it. Without
"branch.*.merge" for the current branch, we are still backward
compatible and follow the "first set of branches" rule.
The real trouble is that some people further argued that pulling
without 'branch.*.merge' when you might not want to follow the
"first set of branches" rule might be a newbie mistake and
should be warned and forbidden. The commit that broke you was
an attempt for that behaviour. I think that newbie protection
intent is good, but the execution was obviously not.
What I have on 'master' has a little fixup to use 'first set of
branches' rule when the fetch gets only one branch without
complaining. I am still not happy with that either, and at this
point I am not sure if there is a good compromise that does not
break existing setup while offering the newbie protection.
Possibilities:
(1) Forget about that "protection" business. If you do not
want mistakes, use 'branch.*.merge' but otherwise we will
continue to follow the good old "first set of branches"
rule.
(2) A slight variant of the above; do the "protection" only
when 'branch.*.merge' is defined for _any_ of the branches,
not just the current branch.
(3) A further variant; do not do the above "protection" if the
current branch is 'master' (this further makes 'master'
special, which some people may hate).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 18:58 ` Junio C Hamano
@ 2006-12-22 20:04 ` Jakub Narebski
2006-12-22 20:16 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-22 20:04 UTC (permalink / raw)
To: git
<opublikowany i wysłany>
Junio C Hamano wrote:
> Possibilities:
>
> (1) Forget about that "protection" business. If you do not
> want mistakes, use 'branch.*.merge' but otherwise we will
> continue to follow the good old "first set of branches"
> rule.
What about marking default branch to merge explicitely using
"Merge:" in remotes/<repo>, or remote.<name>.merge?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 20:04 ` Jakub Narebski
@ 2006-12-22 20:16 ` Junio C Hamano
2006-12-22 20:56 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 20:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> <opublikowany i wysłany>
>
> Junio C Hamano wrote:
>
>> Possibilities:
>>
>> (1) Forget about that "protection" business. If you do not
>> want mistakes, use 'branch.*.merge' but otherwise we will
>> continue to follow the good old "first set of branches"
>> rule.
>
> What about marking default branch to merge explicitely using
> "Merge:" in remotes/<repo>, or remote.<name>.merge?
Sorry, how is that an improvement over the current branch.*.merge?
and how would that help not breaking existing setups?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 20:16 ` Junio C Hamano
@ 2006-12-22 20:56 ` Jakub Narebski
2006-12-22 21:49 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-12-22 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> <opublikowany i wysłany>
>>
>> Junio C Hamano wrote:
>>
>>> Possibilities:
>>>
>>> (1) Forget about that "protection" business. If you do not
>>> want mistakes, use 'branch.*.merge' but otherwise we will
>>> continue to follow the good old "first set of branches"
>>> rule.
>>
>> What about marking default branch to merge explicitely using
>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
>
> Sorry, how is that an improvement over the current branch.*.merge?
> and how would that help not breaking existing setups?
I meant that in addition to forgetting about "protection" business.
This would be intermediate improvement over old behavior, marking
clearly which is default branch to merge (with first branch still
being default, and perhaps error out if there is _only_ wildcard
Pull:/fetch line/variable; the branches marked with + are ineligible
as candidate for merge with "first branch being default branch to
merge" default).
Perhaps make "protection" business optional, default to on for
new users?
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 20:56 ` Jakub Narebski
@ 2006-12-22 21:49 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-22 21:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
> ...
>>>> Possibilities:
>>>>
>>>> (1) Forget about that "protection" business. If you do not
>>>> want mistakes, use 'branch.*.merge' but otherwise we will
>>>> continue to follow the good old "first set of branches"
>>>> rule.
>>>
>>> What about marking default branch to merge explicitely using
>>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
>>
>> Sorry, how is that an improvement over the current branch.*.merge?
>> and how would that help not breaking existing setups?
>
> I meant that in addition to forgetting about "protection" business.
> This would be intermediate improvement over old behavior.
I do not think so. It does not talk about "when on my local
branch X do this", and applies to all pulls from the named
remote. Then longstanding rule of merging the first set of
branches is just fine and as expressive. You see them the first
in the list, and you already know they somehow matter more.
On the other hand, I think Santi's branch.*.merge (done in
commit 5372806a) _was_ a real improvement.
> Perhaps make "protection" business optional, default to on for
> new users?
Now the question is how you would tell "new users".
The possibility (2) is not even good enough, because even old
timers work in a newly cloned repositories.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: What's in git.git (stable)
2006-12-22 9:25 Junio C Hamano
2006-12-22 17:15 ` Randal L. Schwartz
@ 2006-12-22 20:21 ` Quy Tonthat
1 sibling, 0 replies; 601+ messages in thread
From: Quy Tonthat @ 2006-12-22 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement.
[...]
>
> Quy Tonthat (2):
> ...
> Documentation/git-branch: new -r to delete remote-tracking branches.
>
This one is not there on the 'master' branch.
Quy
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2006-12-18 7:26 Junio C Hamano
[not found] ` <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-12-18 7:26 UTC (permalink / raw)
To: git
I've updated 'master' with a handful topics along with a few
fixes:
- Jakub's gitweb updates;
- blame A..B's output shows lines attributed to the boundary
commit with commit SHA-1 prefixed with '^';
- "branch -m $old $new" renames branch.$old.* configuration
variables to branch.$new.*;
- "git add A/B C", when A and C/D used to be tracked files, now
properly works, it used to result in a bogus index you cannot
write-tree out;
- "git show-branch --reflog=<n> <branch>" shows latest n entries
of the reflog of the branch.
- "git fetch" between repositories with tons of refs had huge
performance problem; hopefully fixed.
* The 'master' branch has these since the last announcement.
Jakub Narebski (8):
gitweb: Don't use Content-Encoding: header in git_snapshot
gitweb: Show target of symbolic link in "tree" view
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Do not show difftree for merges in "commit" view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Add "next" link to commit view
Johannes Schindelin (2):
add a function to rename sections in the config
git-branch: rename config vars branch.<branch>.*, too
Junio C Hamano (11):
git-blame: show lines attributed to boundary commits differently.
update-index: make D/F conflict error a bit more verbose.
git-add: remove conflicting entry when adding.
Fix check_file_directory_conflict().
Fix mis-mark-up in git-merge-file.txt documentation
markup fix in svnimport documentation.
Teach show-branch how to show ref-log data.
git-fetch: Avoid reading packed refs over and over again
avoid accessing _all_ loose refs in git-show-ref --verify
show-ref: fix --quiet --verify
show-ref: fix --verify --hash=length
Quy Tonthat (1):
Documentation: new option -P for git-svnimport
Shawn Pearce (1):
Default GIT_COMMITTER_NAME to login name in recieve-pack.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2006-12-16 23:10 Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-16 23:10 UTC (permalink / raw)
To: git
At the end is a list of stuff merged to 'master' since the last
announcement.
----------------------------------------------------------------
Andy Parkins (1):
git-status always says what branch it's on
Brian Gernhardt (2):
Add --add option to git-repo-config
Make git-diff documentation use [--] when it should.
Johannes Schindelin (3):
INSTALL: no need to have GNU diff installed
git-show: grok blobs, trees and tags, too
Document git-merge-file
Junio C Hamano (7):
Revert "git-diff: Introduce --index and deprecate --cached."
git-svn: allow both diff.color and color.diff
Update git-diff documentation
git-fetch: make it work from within a subdirectory.
git-reset: make it work from within a subdirectory.
git-reset [--mixed] <tree> [--] <paths>...
merge: give a bit prettier merge message to "merge branch~$n"
Luben Tuikov (1):
Export PERL_PATH
Nicolas Pitre (2):
repacked packs should be read-only
make commit message a little more consistent and conforting
Quy Tonthat (1):
git-clone documentation
Shawn Pearce (7):
Bypass expensive content comparsion during rename detection.
Avoid accessing a slow working copy during diffcore operations.
Provide more meaningful output from 'git init-db'.
Enable reflogs by default in any repository with a working directory.
Teach bash the new features of 'git show'.
Suggest use of "git add file1 file2" when there is nothing to commit.
Align section headers of 'git status' to new 'git add'.
^ permalink raw reply [flat|nested] 601+ messages in thread
* What's in git.git (stable)
@ 2006-12-06 21:18 Junio C Hamano
2006-12-08 15:36 ` Jakub Narebski
2006-12-09 20:44 ` Tilman Sauerbeck
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-06 21:18 UTC (permalink / raw)
To: git; +Cc: linux-kernel
* The 'maint' branch has produced a new release 1.4.4.2
* In the 'master' branch:
- we now officially favor 'remotes' information to be in
$GIT_DIR/config, and 'git clone' records origin in there,
not in $GIT_DIR/remotes/origin (thanks to Andy Parkins).
- "git send-pack $URL :refs/heads/$branch" can be used to
delete a remote branch (so does "git push $URL :$ref" over
git native protocols).
- built-in shortlog lets you directly say "git shortlog
v2.6.18..master", instead of piping an output from the
corresponding "git log v2.6.18..master" into it.
- git-svn updates
- gitweb updates
- gitk updates
- bash completion updates
The shortlog since the last announcement for 'master' is:
Alex Riesen (2):
git-blame: fix rev parameter handling.
Make perl/ build procedure ActiveState friendly.
Andreas Ericsson (2):
ls-files: Give hints when errors happen.
git-diff: Introduce --index and deprecate --cached.
Andy Parkins (3):
Use .git/config for storing "origin" shortcut repository
Document git-repo-config --bool/--int options.
De-emphasise the symbolic link documentation.
David Miller (1):
Pass -M to diff in request-pull
Eric Wong (10):
git-svn: use ~/.subversion config files when using SVN:: libraries
git-svn: enable delta transfers during fetches when using SVN:: libs
git-svn: update tests for recent changes
git-svn: error out when the SVN connection fails during a fetch
git-svn: fix output reporting from the delta fetcher
git-svn: color support for the log command
git-svn: documentation updates
git-svn: fix multi-init
git-svn: avoid fetching files twice in the same revision
git-svn: avoid network timeouts for long-running fetches
Han-Wen Nienhuys (1):
ident.c: Trim hint printed when gecos is empty.
J. Bruce Fields (1):
cvs-migration: improved section titles, better push/commit explanation
Jakub Narebski (4):
gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
git-clone: Rename --use-immingled-remote option to --no-separate-remote
Document git-diff whitespace flags -b and -w
gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view
Jim Meyering (1):
Set permissions of each new file before "cvs add"ing it.
Johannes Schindelin (10):
Build in shortlog
shortlog: do not crash on parsing "[PATCH"
shortlog: read mailmap from ./.mailmap again
shortlog: handle email addresses case-insensitively
shortlog: fix "-n"
shortlog: use pager
sha1_object_info(): be consistent with read_sha1_file()
git-mv: search more precisely for source directory in index
diff -b: ignore whitespace at end of line
cvs-migration document: make the need for "push" more obvious
Junio C Hamano (24):
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
merge: allow merging into a yet-to-be-born branch.
Store peeled refs in packed-refs (take 2).
git-fetch: reuse ls-remote result.
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: allow glob pattern in refspec
Allow git push to delete remote ref.
git-shortlog: fix common repository prefix abbreviation.
git-shortlog: make common repository prefix configurable with .mailmap
git-fetch: allow forcing glob pattern in refspec
fetch-pack: do not barf when duplicate re patterns are given
git-merge: tighten error checking.
git-merge: do not leak rev-parse output used for checking internally.
cvsimport: style fixup.
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
git-merge: fix confusion between tag and branch
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
git-reset to remove "$GIT_DIR/MERGE_MSG"
git-merge: squelch needless error message.
git-merge: fix "fix confusion between tag and branch" for real
Michael Loeffler (1):
git-fetch: ignore dereferenced tags in expand_refs_wildcard
Nicolas Pitre (2):
builtin git-shortlog is broken
pack-objects: remove redundent status information
Paul Mackerras (1):
gitk: Fix enabling/disabling of menu items on Mac OS X
René Scharfe (1):
shortlog: remove range check
Sean Estabrooks (1):
Update documentation to remove incorrect GIT_DIFF_OPTS example.
Shawn O. Pearce (15):
Teach git-completion.bash how to complete git-merge.
Hide plumbing/transport commands from bash completion.
Teach bash how to complete options for git-name-rev.
Add current branch in PS1 support to git-completion.bash.
Teach bash how to complete git-format-patch.
Teach bash how to complete git-cherry-pick.
Teach bash how to complete git-rebase.
Teach bash about git log/show/whatchanged options.
Support bash completion of refs/remote.
Teach bash about git-repo-config.
Support --strategy=x completion in addition to --strategy x.
Cache the list of merge strategies and available commands during load.
Teach bash about git-am/git-apply and their whitespace options.
Teach bash how to complete long options for git-commit.
Fix broken bash completion of local refs.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
@ 2006-11-14 16:42 Carl Worth
2006-11-14 18:55 ` Andy Whitcroft
0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-14 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
As has been discussed recently, update-index isn't intended as a
"porcelain" command so the mention of it in the output of git-commit
does lead to some user confusion.
---
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 7dd6857..4edabcd 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
int i;
if (q->nr)
wt_status_print_header("Changed but not updated",
- "use git-update-index to mark for commit");
+ "use \"git commit <files>\" to commit or \"git commit -a\" for all");
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
--
1.4.3.3.gf040
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
2006-11-14 16:42 [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Carl Worth
@ 2006-11-14 18:55 ` Andy Whitcroft
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
2006-11-14 23:30 ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Andy Whitcroft @ 2006-11-14 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
Carl Worth wrote:
> As has been discussed recently, update-index isn't intended as a
> "porcelain" command so the mention of it in the output of git-commit
> does lead to some user confusion.
> ---
> wt-status.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 7dd6857..4edabcd 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
> int i;
> if (q->nr)
> wt_status_print_header("Changed but not updated",
> - "use git-update-index to mark for commit");
> + "use \"git commit <files>\" to commit or \"git commit -a\" for all");
> for (i = 0; i < q->nr; i++)
> wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
> if (q->nr)
> --
> 1.4.3.3.gf040
Are we sure this isn't porcelain-ish? We need to use it in merge
conflict correction and the like? You can't use git-commit there as a
replacement. I'd expect it to be 'git update-index' rather than
'git-update-index' of course.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Cleaning up git user-interface warts
2006-11-14 18:55 ` Andy Whitcroft
@ 2006-11-14 19:22 ` Carl Worth
2006-11-14 19:29 ` Shawn Pearce
` (3 more replies)
2006-11-14 23:30 ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
1 sibling, 4 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 19:22 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]
On Tue, 14 Nov 2006 18:55:51 +0000, Andy Whitcroft wrote:
> Carl Worth wrote:
> > As has been discussed recently, update-index isn't intended as a
> > "porcelain" command so the mention of it in the output of git-commit
> > does lead to some user confusion.
>
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
It was Junio that recently said update-index is plumbing, not
porcelain.
So, the fact that conflict resolution still requires the use of
update-index would just be the next thing to fix. A name for a
replacement to use there could be "git resolve <paths>", (since the
old git-resolve is now officially deprecated). That's a name that
matches what hg uses in this situation, (another option is "resolved"
which is what stg uses, but I think verbs for commands work better in
general).
It would be really nice if none of the "common" commands had a hyphen
in them, for example.
And then, the next phase of my evil plan would be to introduce a -i
option for git-commit making it commit the state in the index. Then
git-commit with no options could work like "git-commit -a" does now,
(with the additional protection of not committing any unmerged
files---that is the new "git resolve" would be required before "git
commit" would work after a conflict). Users who really, really like
the current behavior of git-commit could use the new alias support to
pass the new -i option in order to maintain compatible behavior.
Then, the last thing I'd really like to fix is to allow a usage of
"git merge <branch>" instead of the awkward "git pull . <branch>".
With that, most of the user-interface warts that I regularly run into
with git would be solved. Oh, except it would also be nice to
eliminate the "plumbing" commands in a couple of places:
1) From the "man git" man page
2) From git-<TAB>, (maybe the solution for this is to make
"git <TAB>" work and only do tab-completion for the commands
blessed enough to appear in "git --help"? Also push the tab
completion stuff out as a standard part of packages.
Anyway, now I've just gone and blown all my secret plans for changing
git in ways to make it less intimidating for new users.
For reference, the latest potential batch of new users that I'm
dealing with is the set of Fedora package maintainers who are looking
at replacing CVS for their tree of package-building scripts. They are
currently evaluating systems and liking the interface of hg. Here's
the top of the current thread:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
Here's the report about "git commit -a" confusion that led to my patch
above:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
And here's my reply where I suggest that git UI might still be
improved in these areas:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
@ 2006-11-14 19:29 ` Shawn Pearce
2006-11-14 19:59 ` Carl Worth
2006-11-14 19:47 ` Petr Baudis
` (2 subsequent siblings)
3 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-14 19:29 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
Carl Worth <cworth@cworth.org> wrote:
> 2) From git-<TAB>, (maybe the solution for this is to make
> "git <TAB>" work and only do tab-completion for the commands
> blessed enough to appear in "git --help"? Also push the tab
> completion stuff out as a standard part of packages.
Uh, see contrib/completion/git-completion.bash.
"git <TAB>" completes commands. It offers too many completions
for your taste it sounds like, as it also offers plumbing... but
that's fixable. :-)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:29 ` Shawn Pearce
@ 2006-11-14 19:59 ` Carl Worth
0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 19:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Whitcroft, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Tue, 14 Nov 2006 14:29:14 -0500, Shawn Pearce wrote:
> Uh, see contrib/completion/git-completion.bash.
Oops. I had seen this and thought I had installed it properly a while
ago, (copied it to /etc/bash_completion.d/git), but I hadn't realized
it wasn't active in the shell I used to test while composing that
email.
> "git <TAB>" completes commands. It offers too many completions
> for your taste it sounds like, as it also offers plumbing... but
> that's fixable. :-)
Yes, I think we'd all be better off if we could designate some subset
of the current git commands as not being intended for users to type on
the command line and pulled them out of the completion scripts.
It is tough though. Looking through what's available in the short list
from "git --help" I notice that update-index isn't there, and that's
currently still required, (as we've been discussing here). But even
things as "core plumbing" as git rev-list I find extremely useful on
the command like with simple pipelines.
On the other hand, there are definitely some commands I've never
typed, and are not intended to be typed by the user. Here are a few I
see as fairly obvious just from skimming the list:
merge-*
http-*
ssh-*
upload-*
mktag
mktree
check-ref-format
...
There are a bunch of others as well. Maybe it would be easier to start
with the list in git --help and see what should be added to that.
The documentation for some of the above commands have phrases such as
"Invoked by <other command>" and "usually not invoked by the end user"
which does make the distinction quite clear. So it would be nice if
git could keep these away from the user more.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
2006-11-14 19:29 ` Shawn Pearce
@ 2006-11-14 19:47 ` Petr Baudis
2006-11-14 20:56 ` Carl Worth
2006-11-14 20:46 ` Karl Hasselström
2006-11-14 20:52 ` Nicolas Pitre
3 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-14 19:47 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
On Tue, Nov 14, 2006 at 08:22:39PM CET, Carl Worth wrote:
> For reference, the latest potential batch of new users that I'm
> dealing with is the set of Fedora package maintainers who are looking
> at replacing CVS for their tree of package-building scripts. They are
> currently evaluating systems and liking the interface of hg. Here's
> the top of the current thread:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
>
> Here's the report about "git commit -a" confusion that led to my patch
> above:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
>
> And here's my reply where I suggest that git UI might still be
> improved in these areas:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html
Hmm, did they (not) consider Cogito? They wouldn't have those issues.
;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:47 ` Petr Baudis
@ 2006-11-14 20:56 ` Carl Worth
2006-11-15 0:31 ` Junio C Hamano
2006-11-17 20:30 ` Steven Grimm
0 siblings, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 20:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andy Whitcroft, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
I didn't ask.
Frankly, I don't see a lot of value in the git/cogito split right now.
When I first learned git and cogito (January 2006) and switched cairo
from cvs to git (the repository storage), I recommended cogito to
cairo programmers as a "more cvs-like" way to work with the new
repository.
Since then, having worked with git (the command-line program)
exclusively for my own work, and having introduced it to dozens of new
users, I don't bother recommending cogito anymore. It's just not that
hard to learn git itself, so there's not that much value in learning
cogito instead.
And this is particularly true since there's quite a large cost to
having to learn cogito _in addition to_ git. And I think that's what
most people would have to do anyway. For example, cogito doesn't wrap
all git commands. So users have to dip down into git for things like
git-bisect or else miss out an important functionality.
And for something like the Fedora transition, where I'm working with
the people who will be training the community in the new tools, the
trainers would have to learn both if they want to support a community
using both git and cogito. These trainers are already complaining
about the ~140 git commands, so adding 40 more cogito commands as well
doesn't make the story better.
It's great that git is written in a script-friendly way so that new
interfaces can be built on top of it. And I think the benefits of new
user interfaces are clear when they work in fundamentally different
ways, (say, being operated through a GUI). But where git and cogito
are both command-line utilities and have the same basic functionality,
I don't see how its helpful to maintain both tools. (Certainly some of
my attitude here is due to the timing of my introduction to git
contrasted with the timing of the inception of cogito. I'm sure git
improved a lot between those two events.)
There are some things that cogito does that git does not that I would
like to have in git. One is having a "commit" command that commits
everything by default without an extra command-line option. Another
(that I _think_ cogito has) is a way to switch away from a branch with
dirty changes to a clean branch, do work there, and come back to the
original branch with the dirty stuff still there.
I don't see any defining difference that justifies cogito's
existence ("hide the index" maybe? let's just hide it a tiny bit more
in git). And I would like to help work to get the remaining good
stuff that has been proven in cogito---to get it pushed down into git
itself.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 20:56 ` Carl Worth
@ 2006-11-15 0:31 ` Junio C Hamano
2006-11-15 4:08 ` Petr Baudis
2006-11-15 20:51 ` Carl Worth
2006-11-17 20:30 ` Steven Grimm
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 0:31 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Andy Whitcroft, Petr Baudis
Carl Worth <cworth@cworth.org> writes:
> On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
>> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
>
> I didn't ask.
>
> Frankly, I don't see a lot of value in the git/cogito split right now.
> ...
> It's great that git is written in a script-friendly way so that new
> interfaces can be built on top of it. And I think the benefits of new
> user interfaces are clear when they work in fundamentally different
> ways, (say, being operated through a GUI). But where git and cogito
> are both command-line utilities and have the same basic functionality,
> ...
> There are some things that cogito does that git does not that I would
> like to have in git.
> ...
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
I am of two minds here.
I do not think the Porcelain-ish UI that is shipped with git
should be taken with the same degree of "authority" as git
Plumbing. The plumbing needed to have something that worked for
one particular workflow (namely, workflow of the people in the
integrator role of kernel-style project) and that is where the
current set of Porcelain-ish originates. Linus works primarily
as an integrator so the toolsets he did tend to be more pleasant
to use for integrators and less so for contributors. I started
as a contributor and added some commands like format-patch and
rebase that Linus never would have felt the need for. I think
single isolated developers, contributors and CVS style shared
repository usage could be a lot improved because neither of us
were concentrating in their workflows. This needs somebody
motivated enough to improve things in that area. For example,
StGIT with its 'float' command is a great improvement over what
rebase does for people in the contributor role.
By now, perhaps git may be good enough for the kernel folks,
even for those not in the integrator role, but I have no doubt
that they have many dislikes to the way some commands work.
They and X.org folks are using git primarily because Linus and
Keith forced them to ;-), and being interoperable is more
important than having to tolerate sucky UI here and there.
Everybody knows that git Porcelain-ish sucks, and making it more
usable is a worthy goal.
But making it more usable for whom is a big question.
Quite frankly, I do not think there can be _the_ single UI that
would satisfy different types of workflows for some of the
commands. The commands related to software archaeology, in
which my main interest and strength lie, would easily be usable
across workflows, but commands to build commits locally and
propagate them to and from other repositories would be affected
by the workflow.
For example, fetching and merging from many places without
necessarily having corresponding tracking branches is a great
thing for people in the integrator role. On the other hand, for
people doing CVS-style centralized repository interaction, it is
often more useful to have tracking branches. You could support
both but it has been painful.
For another example, having a commit command to commit
everything by default is disastrous for people who allow their
workflows to often be interrupted. When I respond to a message
from the list with an example patch, my repository is often in
the middle of doing something completely unrelated, and I edit
and make diff to send the message out and I do not necessarily
revert that change afterwards immediately. For more organized
people it may not be a problem so you either support both types
of workflows or do a specialized toolset.
It is not just command line syntax and the defaults, but
concepts as well. People in the integrator role often need to
deal with merges and you would need to be aware of the role of
the index and need to be able to manipulate the index, a lot
more often than people in the contributor role. To satisify
both kinds of workflows, you would either have switches, or do a
specialized toolset, like Cogito, that tries to hide the index.
A Porcelain that does a very similar thing in slightly different
way is obviously a waste, but otherwise I do not think it is a
problem to have different Porcelains. StGIT does not compete
with the "sucky" Porcelain-ish shipped with git but makes the
user's life a lot more pleasant by complementing what the sucky
one does not do well. It is not very useful while I am playing
the integrator role, but when I am doing my own thing it is a
great addition to my toolchest.
I am from the camp that does _not_ want to hide the index, so
obviously I do not see any value in its effort to hide the
index. But other aspects of it, most notably being friendly to
simpler workflows, is a very good thing.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 0:31 ` Junio C Hamano
@ 2006-11-15 4:08 ` Petr Baudis
2006-11-15 4:33 ` Junio C Hamano
2006-11-15 10:05 ` Jakub Narebski
2006-11-15 20:51 ` Carl Worth
1 sibling, 2 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 4:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft
On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> >> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
> >
> > I didn't ask.
> >
> > Frankly, I don't see a lot of value in the git/cogito split right now.
> > ...
> > It's great that git is written in a script-friendly way so that new
> > interfaces can be built on top of it. And I think the benefits of new
> > user interfaces are clear when they work in fundamentally different
> > ways, (say, being operated through a GUI). But where git and cogito
> > are both command-line utilities and have the same basic functionality,
> > ...
> > There are some things that cogito does that git does not that I would
> > like to have in git.
> > ...
> > I don't see any defining difference that justifies cogito's
> > existence ("hide the index" maybe? let's just hide it a tiny bit more
> > in git). And I would like to help work to get the remaining good
> > stuff that has been proven in cogito---to get it pushed down into git
> > itself.
>
> I am of two minds here.
>
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.
..snip passage about workflows..
Controversy's fun, so...
<Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
saying this.)
From the current perspective, I think it has been a mistake that the
porcelain and plumbing was not kept separate in independent packages,
and perhaps even maintained separately (and perhaps not; at least having
a single tree with plumbing/ and porcelain/ directories and separate
packages in distributions might already help something), so that "git"
would be kept as a kind of library and then there would be a separate
package providing an interface to it. Or you could select one of several
packages. Not only would that make Cogito prevail in the world and bring
me a flood of marriage proposals, but look at how would it help the
general public:
(i) Clearly divided porcelain/plumbing interface, so that you can
really isolate the two UI-wise; endless confusion reigns there now. Is
git-update-index porcelain or plumbing? _You_ call git-merge a proper
porcelain? From my perspective, git-update-ref is as plumbing as it
gets, but it's classified as porcelain. Etc, etc. This would be by far
the most important advantage.
(ii) The plumbing and porcelain would not share the same namespace,
leading to clearer UI. (I'm just inflating (i).)
(iii) The documentation would not be a strange mix of porcelain and
plumbing. (More (i) inflation.)
(iv) (i) is troublesome because I have a feeling that Junio declared
several times that he doesn't care that much about stable API for
porcelain compared to the plumbing. But with the current mix it's
desirable to use some porcelain even in other porcelains and in scripts.
(v) Git would be properly libified by now. If you wanted to convert
bits of porcelain to C, it would be at least much higher priority.
(vi) You wouldn't need to make the gruesome choice on what is the
canonical workflow the _the_ Git porcelain supports (see the snipped
passage). Or you would, but it would have less impact.
(vii) The world would be a happier place.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:08 ` Petr Baudis
@ 2006-11-15 4:33 ` Junio C Hamano
2006-11-15 4:46 ` Nicolas Pitre
2006-11-15 20:39 ` Petr Baudis
2006-11-15 10:05 ` Jakub Narebski
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 4:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
>>
>> I am of two minds here.
>>
>> I do not think the Porcelain-ish UI that is shipped with git
>> should be taken with the same degree of "authority" as git
>> Plumbing.
> ..snip passage about workflows..
>
> Controversy's fun, so...
>
> <Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
> saying this.)
It appears that you are not grumpy as you were anymore ;-). I
mostly agree with what you said in your message.
> (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.
Yes. The current "merge" started its life as Linus's porcelain
(we did not have fetch and pull infrastructure back then) but
quickly has become just a helper for pull to produce a merge
commit. If anybody thinks its UI is good as a general end-user
level command, there is a need for "head examination".
As you say, update-ref is as plumbing as it gets and it should
not be listed as Porcelain; I am a bit surprised that it is
labelled as such myself.
No disagreement here, nor (ii) nor (iii).
> (ii) The plumbing and porcelain would not share the same namespace,
> leading to clearer UI. (I'm just inflating (i).)
>
> (iii) The documentation would not be a strange mix of porcelain and
> plumbing. (More (i) inflation.)
>
> (iv) (i) is troublesome because I have a feeling that Junio declared
> several times that he doesn't care that much about stable API for
> porcelain compared to the plumbing. But with the current mix it's
> desirable to use some porcelain even in other porcelains and in scripts.
This is true and it is a problem.
While we encourage Porcelain writers to use plumbing in order to
give git Porcelain-ish more freedom to evolve to give better UI
for humans, not having a clear distinction between the two makes
it harder.
> (v) Git would be properly libified by now. If you wanted to convert
> bits of porcelain to C, it would be at least much higher priority.
I am not sure about "libified" part and I do not know what bits
of porcelain wants to become C right now. But I do not think
this point is important part of your list.
> (vi) You wouldn't need to make the gruesome choice on what is the
> canonical workflow the _the_ Git porcelain supports (see the snipped
> passage). Or you would, but it would have less impact.
Yes. This is really important.
Linus and me having done Porcelain-ish that supports integrator
role workflow better than other workflows such as contributor
role should not discourage people from working on alternative or
complementary Porcelains to help other workflows better (see the
snipped passage).
StGIT sets a great example, and efforts like it is encoraged
more.
I think both Linus and myself tried to make it clear that the
purpose of Porcelain-ish that comes with core git is 50% to make
plumbing (perhaps minimally) usable and the other 50% to serve
as an example for Porcelain writers to learn how to use the
plumbing, but we should probably have stressed the latter
better.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:33 ` Junio C Hamano
@ 2006-11-15 4:46 ` Nicolas Pitre
2006-11-15 10:09 ` Jakub Narebski
2006-11-15 20:39 ` Petr Baudis
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Yes. The current "merge" started its life as Linus's porcelain
> (we did not have fetch and pull infrastructure back then) but
> quickly has become just a helper for pull to produce a merge
> commit. If anybody thinks its UI is good as a general end-user
> level command, there is a need for "head examination".
If you mean "git merge" it sure needs to be brought forward. It can't
be clearer than:
git-merge the_other_branch
or
git-merge git://repo.com/time_machine.git
to instantaneously understand what is going on.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:46 ` Nicolas Pitre
@ 2006-11-15 10:09 ` Jakub Narebski
2006-11-15 10:15 ` Santi Béjar
2006-11-15 14:56 ` Nicolas Pitre
0 siblings, 2 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:09 UTC (permalink / raw)
To: git
Nicolas Pitre wrote:
> On Tue, 14 Nov 2006, Junio C Hamano wrote:
>
>> Yes. The current "merge" started its life as Linus's porcelain
>> (we did not have fetch and pull infrastructure back then) but
>> quickly has become just a helper for pull to produce a merge
>> commit. If anybody thinks its UI is good as a general end-user
>> level command, there is a need for "head examination".
>
> If you mean "git merge" it sure needs to be brought forward. It can't
> be clearer than:
>
> git-merge the_other_branch
>
> or
>
> git-merge git://repo.com/time_machine.git
>
> to instantaneously understand what is going on.
You mean
git merge git://repo.com/time_machine.git#branch
don't you (perhaps with 'master' as default branch)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:09 ` Jakub Narebski
@ 2006-11-15 10:15 ` Santi Béjar
2006-11-15 10:28 ` Jakub Narebski
2006-11-15 14:56 ` Nicolas Pitre
1 sibling, 1 reply; 601+ messages in thread
From: Santi Béjar @ 2006-11-15 10:15 UTC (permalink / raw)
To: git
On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Nicolas Pitre wrote:
>
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> >
> >> Yes. The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit. If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> >
> > If you mean "git merge" it sure needs to be brought forward. It can't
> > be clearer than:
> >
> > git-merge the_other_branch
> >
> > or
> >
> > git-merge git://repo.com/time_machine.git
> >
> > to instantaneously understand what is going on.
>
> You mean
>
> git merge git://repo.com/time_machine.git#branch
>
> don't you (perhaps with 'master' as default branch)?
perhaps with remote 'HEAD' as default branch?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:15 ` Santi Béjar
@ 2006-11-15 10:28 ` Jakub Narebski
2006-11-16 2:43 ` Petr Baudis
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:28 UTC (permalink / raw)
To: git
Santi Béjar wrote:
> On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> You mean
>>
>> git merge git://repo.com/time_machine.git#branch
>>
>> don't you (perhaps with 'master' as default branch)?
>
> perhaps with remote 'HEAD' as default branch?
No! HEAD might change without your notice, and you want to know
which branch you merge. With remotes the default could be first
branch in the pull/fetch list, but with bare URL...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:28 ` Jakub Narebski
@ 2006-11-16 2:43 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 2:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Wed, Nov 15, 2006 at 11:28:27AM CET, Jakub Narebski wrote:
> Santi Béjar wrote:
>
> > On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
>
> >> You mean
> >>
> >> git merge git://repo.com/time_machine.git#branch
> >>
> >> don't you (perhaps with 'master' as default branch)?
> >
> > perhaps with remote 'HEAD' as default branch?
>
> No! HEAD might change without your notice, and you want to know
> which branch you merge. With remotes the default could be first
> branch in the pull/fetch list, but with bare URL...
No! If HEAD changed without your notice, it means that the remote
repository admin _wants_ you to start fetching another branch now.
Imagine a setup of these branches:
phooey-1.2 legacy lineage
phooey-2.0 last stable
phooey-3.0 current development (no releases yet)
phooey-4.0 stash for futuristic functionality, heavily
experimental
In this case, HEAD now points to phooey-3.0 but when it becomes stable,
it would change to phooey-4.0.
The common practice of having 'master' pointing on whatever you
currently have now and and "cutting out" the branches from it at random
times is something heavily influenced by CVS where this is the only sane
way of branching (the cutting out even hardcoded in numbering scheme).
In more advanced systems, you may want to be much more flexible wrt. this
(note that I'm not saying you necessarily _should_ be).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:09 ` Jakub Narebski
2006-11-15 10:15 ` Santi Béjar
@ 2006-11-15 14:56 ` Nicolas Pitre
1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 14:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Wed, 15 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
>
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> >
> >> Yes. The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit. If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> >
> > If you mean "git merge" it sure needs to be brought forward. It can't
> > be clearer than:
> >
> > git-merge the_other_branch
> >
> > or
> >
> > git-merge git://repo.com/time_machine.git
> >
> > to instantaneously understand what is going on.
>
> You mean
>
> git merge git://repo.com/time_machine.git#branch
>
> don't you (perhaps with 'master' as default branch)?
Something like that. I wantee to enphasize on the "merge" command that
should deal with, hey, merges.
I don't know if # is a good choice for branch indicator though.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:33 ` Junio C Hamano
2006-11-15 4:46 ` Nicolas Pitre
@ 2006-11-15 20:39 ` Petr Baudis
1 sibling, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Nov 15, 2006 at 05:33:03AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > (v) Git would be properly libified by now. If you wanted to convert
> > bits of porcelain to C, it would be at least much higher priority.
>
> I am not sure about "libified" part and I do not know what bits
> of porcelain wants to become C right now. But I do not think
> this point is important part of your list.
Merge strategies. Or wait, is that already plumbing?
Or git-status. git-add. Plenty more.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:08 ` Petr Baudis
2006-11-15 4:33 ` Junio C Hamano
@ 2006-11-15 10:05 ` Jakub Narebski
2006-11-15 10:25 ` Karl Hasselström
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 10:05 UTC (permalink / raw)
To: git
Petr Baudis wrote:
> (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.
The problem is that one man's plumbing is another man porcelain.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 0:31 ` Junio C Hamano
2006-11-15 4:08 ` Petr Baudis
@ 2006-11-15 20:51 ` Carl Worth
2006-11-15 20:57 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft, Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 6788 bytes --]
On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.
I think we should fix this. "This is great technology with a crap
interface on top" really isn't a good story. I don't actually agree
with that---I don't think the git interface is really all that bad,
it's just got a few little things that tend to trip up new users in my
experience.
And what git does really well, (history exploring, allowing for
pipeline on-liners to iterate over revisions in A..B), are things that
don't even exist in other tools, nor even in the "alternate"
porcelains for git. This stuff is where git's interface is really
fantastic, and it would be a shame to write it off.
> I think
> single isolated developers, contributors and CVS style shared
> repository usage could be a lot improved because neither of us
> were concentrating in their workflows. This needs somebody
> motivated enough to improve things in that area. For example,
> StGIT with its 'float' command is a great improvement over what
> rebase does for people in the contributor role.
Yes, there are some specific workflow-oriented operations that git
doesn't handle as well as it could. Things like commit --amend are
certainly improvements. One that is still totally broken is "follow
all the development in another repository" where clone followed by
repeated fetch doesn't do the job as soon as the remote adds or
deletes a branch.
> But making it more usable for whom is a big question.
>
> Quite frankly, I do not think there can be _the_ single UI that
> would satisfy different types of workflows for some of the
> commands.
I strongly disagree. Or at least, I don't think we've tried hard
enough yet that we should give up on this.
I do agree that people in different roles will have different lists of
"most used operations" and that some operations won't appear on some
users lists at all, (someone who's just "watching" development won't
commit or merge, for example---[or so they thing when they start]).
But I really don't think that for any given operation that different
roles impose a different desire on the behavior of the operation. We
have different people with different background and disagreement on
names and silly things like that, but I don't think that's related to
the roles in which they are working with the tool.
> For example, fetching and merging from many places without
> necessarily having corresponding tracking branches is a great
...
I don't think we've ever had this right in git. The new
--use-separate-remotes stuff or similar will start to help as it
becomes the default. I don't see how this won't benefit everybody.
> For another example, having a commit command to commit
> everything by default is disastrous for people who allow their
> workflows to often be interrupted.
Workflow-interruption is an important thing to support, but separating
update-index and commit really doesn't address it nearly as much as I
would like. The lack of really good workflow-interruption support has
been one of my longest-running annoyances with git, (perhaps because I
have a problem with trying to do too many things at once). Git can
create and change branches fast enough that it really should be able
to help me better with this. The only missing piece is being able to
stash the dirty stuff on the current branch, to be able to come back
to it later. I've talked a bit about what I would like in this area
before, and I really just need to code it up.
> It is not just command line syntax and the defaults, but
> concepts as well. People in the integrator role often need to
> deal with merges and you would need to be aware of the role of
> the index and need to be able to manipulate the index, ...
Again, I think it's more that the specific operations bring in
concepts, (merge bringing in the index here). As such, someone never
doing a merge could easily get by not having to understand the index.
> A Porcelain that does a very similar thing in slightly different
> way is obviously a waste, but otherwise I do not think it is a
> problem to have different Porcelains. StGIT does not compete
> with the "sucky" Porcelain-ish shipped with git but makes the
> user's life a lot more pleasant by complementing what the sucky
> one does not do well. It is not very useful while I am playing
> the integrator role, but when I am doing my own thing it is a
> great addition to my toolchest.
But even here, there's a bunch of waste in StGit. For example, there
are a lot of commands in StGit whose only purpose is to translate back
and forth between the StGit and non-StGit views of the world, (init,
assimilate, commit, uncommit). Those could all be discarded if the
functionality of StGit were brought down into git itself. Then there
are a myriad of StGit commands which are basically just the same as
their git counterparts.
Now, StGit is a great tool, and I know that it works really well for
some people in the role of just maintaining a stack of changes against
some upstream, and can use StGit alone and never touch "git" the
command-line.
But for someone like me who already uses git regularly, and
occasionally just wants to pop back a few commits, amend it, and then
push again, StGit is not helpful, (the series of init, assimilate, and
uncommits just to get started is prohibitive compared to just working
out the awkward steps needed to make a temporary branch and
rebase). So I'd love to see just a couple of commands added to "git"
to support these kinds of operations more smoothly.
> I am from the camp that does _not_ want to hide the index, so
> obviously I do not see any value in its effort to hide the
> index. But other aspects of it, most notably being friendly to
> simpler workflows, is a very good thing.
I don't think "hide or not-to-hide" is the right way to frame the
discussion about the index. I regularly use update-index to stage
partial commits, and I find that very useful. And obviously the index
is involved in resolving merge conflicts.
But I don't think the user-interface for either of those operations
(partial commit, resolve conflicts), is ideal, and the current
requirement to use either "update-index <paths>" or "commit -a" after
modifying a file for the first time is demonstrably a hangup for a lot
of new users. So I really think it's possible to address both of these
at once.
Anyone, that's enough generic rambling from me without any specific
content. I'll try to keep future messages focused on specific
desirable operations that have problematic interfaces in git right
now, along with proposals for improving them.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:51 ` Carl Worth
@ 2006-11-15 20:57 ` Jakub Narebski
2006-11-15 22:00 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 20:57 UTC (permalink / raw)
To: git
Carl Worth wrote:
>On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
>>
>> For another example, having a commit command to commit
>> everything by default is disastrous for people who allow their
>> workflows to often be interrupted.
>
> Workflow-interruption is an important thing to support, but separating
> update-index and commit really doesn't address it nearly as much as I
> would like. The lack of really good workflow-interruption support has
> been one of my longest-running annoyances with git, (perhaps because I
> have a problem with trying to do too many things at once). Git can
> create and change branches fast enough that it really should be able
> to help me better with this. The only missing piece is being able to
> stash the dirty stuff on the current branch, to be able to come back
> to it later. I've talked a bit about what I would like in this area
> before, and I really just need to code it up.
There is git-stash/git-unstash floating somewhere in the archive.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:57 ` Jakub Narebski
@ 2006-11-15 22:00 ` Shawn Pearce
2006-11-15 22:17 ` Carl Worth
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 22:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> wrote:
> Carl Worth wrote:
> >On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
> >>
> >> For another example, having a commit command to commit
> >> everything by default is disastrous for people who allow their
> >> workflows to often be interrupted.
> >
> > Workflow-interruption is an important thing to support, but separating
> > update-index and commit really doesn't address it nearly as much as I
> > would like. The lack of really good workflow-interruption support has
> > been one of my longest-running annoyances with git, (perhaps because I
> > have a problem with trying to do too many things at once). Git can
> > create and change branches fast enough that it really should be able
> > to help me better with this. The only missing piece is being able to
> > stash the dirty stuff on the current branch, to be able to come back
> > to it later. I've talked a bit about what I would like in this area
> > before, and I really just need to code it up.
>
> There is git-stash/git-unstash floating somewhere in the archive.
I find that a "git commit -a -m parked; git checkout -b ..." works
well to stash my current stuff off. Then I just amend the commit
when I come back to that branch.
The problem I just ran into today was "git checkout" doesn't double
check the file stat data against the index before switching branches.
If the file is unchanged between the two branches there's no error.
So I switched branches with dirty files that I forgot to park on
the old branch.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 22:00 ` Shawn Pearce
@ 2006-11-15 22:17 ` Carl Worth
0 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
On Wed, 15 Nov 2006 17:00:54 -0500, Shawn Pearce wrote:
> > There is git-stash/git-unstash floating somewhere in the archive.
Yes, I did write those once upon a time. ;-)
It's the manual stash/unstash that I don't want though. I want to be
able to make this happen automatically when switching branches.
> I find that a "git commit -a -m parked; git checkout -b ..." works
> well to stash my current stuff off. Then I just amend the commit
> when I come back to that branch.
Yes, I do stuff like that as well. And often "reset HEAD~" instead of
amend, (always with a moment's pause as reset justly deserves).
> The problem I just ran into today was "git checkout" doesn't double
> check the file stat data against the index before switching branches.
> If the file is unchanged between the two branches there's no error.
> So I switched branches with dirty files that I forgot to park on
> the old branch.
Right, so that's just more evidence that this approach is a little
awkward.
Anyway, the stashing thing I want is a minor thing that should be easy
to fix in git, (as is everything we're talking about here I think).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 20:56 ` Carl Worth
2006-11-15 0:31 ` Junio C Hamano
@ 2006-11-17 20:30 ` Steven Grimm
2006-11-17 21:35 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Steven Grimm @ 2006-11-17 20:30 UTC (permalink / raw)
To: git
Jumping into this a day late, but:
Carl Worth wrote:
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
>
Agreed totally on the second point. It would be great if git natively
supported everything people use in Cogito.
I find myself using native git commands for the most part, except for
one Cogito command: "cg-update". It is vastly more convenient than
git-pull in large part because it automatically merges upstream changes
with uncommitted working-copy changes. I suppose you could classify this
as "hide the index" in some sense.
Maybe I should give an example of what I mean. Suppose I have two child
repositories (owned by different developers, say):
cg-clone repo child1
cg-clone repo child2
Now I go into both of them and make different (hopefull non-conflicting)
edits to the same file.
echo foo >> child1/testfile
perl -pi -e 's/tree/shrub/' child2/testfile
I push the change from child1 into the integration repo.
cd child1
git-commit -a
git-push
Now I want to incorporate the change into child2, where I'm still doing
work. With Cogito, I go to child2 and run:
cg-update
and afterwards, the upstream changes are merged into testfile and "git
diff" still shows my local edits. With Git native commands, updating
child2 if I'm not ready to commit yet is more like:
git-diff --binary > /tmp/patch
git-reset --hard
git-pull
git-apply /tmp/patch
I might have gotten that slightly wrong, but I think I have the general
idea right; in any event, it's not nearly as convenient! The alternative
is to commit then pull, but then when I want to look at my local edits,
I have to remember to diff my working copy against the correct revision,
which gets increasingly annoying if I update more than once.
Like others on this list, I'm also trying to sell an existing user base
(in this case, they're using Subversion) on Git. The lack of a built-in
equivalent to "svn update" is actually a pretty big UI annoyance for
people whose workflow doesn't require git's more sophisticated feature
set at a given point in time. Even a sophisticated user doesn't need the
full power of the tool 100% of the time, so this isn't just a novice vs.
expert thing in my opinion.
Absent Cogito, would the lack of a simple "svn update" equivalent be a
deal-killing "throw your hands up in disgust and give up" thing? Maybe
not, but it's a daily "ugh, why am I having to type extra commands to do
something that only took one command in svn?" thing. So it's nice to
have Cogito to paper over that particular wart.
If there is a native git equivalent to cg-update including the
working-copy automatic merges, I'll be delighted to stand corrected!
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 20:30 ` Steven Grimm
@ 2006-11-17 21:35 ` Junio C Hamano
2006-11-17 22:07 ` Petr Baudis
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 21:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
Steven Grimm <koreth@midwinter.com> writes:
> echo foo >> child1/testfile
> perl -pi -e 's/tree/shrub/' child2/testfile
>...
> git-diff --binary > /tmp/patch
> git-reset --hard
> git-pull
> git-apply /tmp/patch
>
> I might have gotten that slightly wrong, but I think I have the
> general idea right.
stg pull would help you in such a situation as well, but I see
what you mean.
Just like we have an explicit -m option to "checkout" to allow
file-level merging of local changes, I think it is reasonable to
hav an option that allows file-level merging of local changes
when doing a pull that you _know_ will not conflict.
When there will be a conflict between your HEAD and MERGE_HEAD
even without your local changes, you somehow need to sort out
the resulting mess that come from conflicts due to the branch
diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between
your local change and what the other branch did. The resulting
merge commit obviously needs to record resolutions only to the
former and should not even record anything you did locally,
conflicted or not. Which is a pain for the end user and giving
them a way to revert to the state before this three-and-half
way merge started also needs to be there.
Unfortunately the only way to know if there will be a file-level
conflict is to try one, and stashing away the current state just
in case it conflicted is a performance penalty, so this probably
should stay as an option just like "-m" to the "checkout".
But the basic mechanism to do this three-and-half way merge is
simple and I have no objection if somebody wanted to add such an
option to "git pull".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 21:35 ` Junio C Hamano
@ 2006-11-17 22:07 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-17 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
On Fri, Nov 17, 2006 at 10:35:04PM CET, Junio C Hamano wrote:
> Unfortunately the only way to know if there will be a file-level
> conflict is to try one, and stashing away the current state just
> in case it conflicted is a performance penalty, so this probably
> should stay as an option just like "-m" to the "checkout".
I think it would be just great if it worked at least for fast-forwarding
case; I think this is where it is actually most useful. Cogito tries to
support even the three-way case as long as the changes touch different
files, but I'm not sure if it was a good idea to begin with.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
2006-11-14 19:29 ` Shawn Pearce
2006-11-14 19:47 ` Petr Baudis
@ 2006-11-14 20:46 ` Karl Hasselström
2006-11-14 20:52 ` Nicolas Pitre
3 siblings, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-14 20:46 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
On 2006-11-14 11:22:39 -0800, Carl Worth wrote:
> So, the fact that conflict resolution still requires the use of
> update-index would just be the next thing to fix. A name for a
> replacement to use there could be "git resolve <paths>", (since the
> old git-resolve is now officially deprecated). That's a name that
> matches what hg uses in this situation, (another option is
> "resolved" which is what stg uses, but I think verbs for commands
> work better in general).
Yes, "resolve" sounds better than "resolved". The latter is arguably
more correct, since you're telling git that you have already resolved
the file and not asking it to resolve it for you, but I still prefer
"resolve".
> And then, the next phase of my evil plan would be to introduce a -i
> option for git-commit making it commit the state in the index. Then
> git-commit with no options could work like "git-commit -a" does now,
> (with the additional protection of not committing any unmerged
> files---that is the new "git resolve" would be required before "git
> commit" would work after a conflict). Users who really, really like
> the current behavior of git-commit could use the new alias support
> to pass the new -i option in order to maintain compatible behavior.
Seems very sane. Default to simple behavior, and provide a switch to
get more complicated behavior.
> Then, the last thing I'd really like to fix is to allow a usage of
> "git merge <branch>" instead of the awkward "git pull . <branch>".
This should reduce newbie confusion a lot.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
` (2 preceding siblings ...)
2006-11-14 20:46 ` Karl Hasselström
@ 2006-11-14 20:52 ` Nicolas Pitre
2006-11-14 21:01 ` Jakub Narebski
2006-11-14 21:10 ` Carl Worth
3 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 20:52 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
On Tue, 14 Nov 2006, Carl Worth wrote:
> Anyway, now I've just gone and blown all my secret plans for changing
> git in ways to make it less intimidating for new users.
I just cannot do otherwise than cheer this with applause.
Even if I have a clear preference for GIT's _technology_, I still think
that the HG user interface is more convivial. I even been thinking
about writing something like an hg-like frontend to GIT from time to
time just so that GIT could then be better compared to (and actually
just used like) HG.
I still think that the GIT user interface sucks in many ways. The
confusion between pull, fetch and push is still my favorite, along with
the locale vs remote branch issue. Maybe we'll better handle the branch
issue eventually, but it would be so much intuitive to split branch
merging out of git-pull, and make git-pull be the same as git-fetch
(maybe deprecating git-fetch in the process) so push and pull are really
_only_ opposite of each other.
If the fetch+merge behavior (which I think should really be refered as
pull+merge) is still desirable, then it should be called git-update and
be no more than a single shell script line such as
git_pull && git_merge"
This is really what most people expect from such a command name based
on obvious historical reasons. The lack of any branch argument to
git-pull and git-merge could be defined as using the first defined
remote branch by default. But having git-pull performing merges is IMHO
overloading the word and goes against most people's expectations.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 20:52 ` Nicolas Pitre
@ 2006-11-14 21:01 ` Jakub Narebski
2006-11-14 21:32 ` Nicolas Pitre
2006-11-14 21:10 ` Carl Worth
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 21:01 UTC (permalink / raw)
To: git
Nicolas Pitre wrote:
> If the fetch+merge behavior (which I think should really be refered as
> pull+merge) is still desirable, then it should be called git-update and
> be no more than a single shell script line such as
>
> git_pull && git_merge"
>
> This is really what most people expect from such a command name based
> on obvious historical reasons. The lack of any branch argument to
> git-pull and git-merge could be defined as using the first defined
> remote branch by default. But having git-pull performing merges is IMHO
> overloading the word and goes against most people's expectations.
By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
repository)?
We can always have --merge arguments to git-pull, and --fetch argument to
git-merge.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:01 ` Jakub Narebski
@ 2006-11-14 21:32 ` Nicolas Pitre
2006-11-14 22:04 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 21:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1241 bytes --]
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
>
> > If the fetch+merge behavior (which I think should really be refered as
> > pull+merge) is still desirable, then it should be called git-update and
> > be no more than a single shell script line such as
> >
> > git_pull && git_merge"
> >
> > This is really what most people expect from such a command name based
> > on obvious historical reasons. The lack of any branch argument to
> > git-pull and git-merge could be defined as using the first defined
> > remote branch by default. But having git-pull performing merges is IMHO
> > overloading the word and goes against most people's expectations.
>
> By the way, is anyone doing _remote_ octopus pull (true pull, not with . as
> repository)?
>
> We can always have --merge arguments to git-pull, and --fetch argument to
> git-merge.
That would be a complete abomination if you want my opinion.
Please let git-pull actually pull stuff from a remote place, and
git-merge actually merge stuff only. Let's keep simple concepts mapped
to simple commands please. Nothing prevents _you_ from scripting more
involved operations with a single command of your liking afterwards.
Nicolas
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:32 ` Nicolas Pitre
@ 2006-11-14 22:04 ` Jakub Narebski
2006-11-14 22:29 ` Nicolas Pitre
0 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 22:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre wrote:
> On Tue, 14 Nov 2006, Jakub Narebski wrote:
>> We can always have --merge arguments to git-pull, and --fetch argument to
>> git-merge.
>
> That would be a complete abomination if you want my opinion.
>
> Please let git-pull actually pull stuff from a remote place, and
> git-merge actually merge stuff only. Let's keep simple concepts mapped
> to simple commands please. Nothing prevents _you_ from scripting more
> involved operations with a single command of your liking afterwards.
Do we want to abandon completely "single-branch" workflow, where you
don't use tracking branch, only merge directly into your working branch?
That is the cause to (unused by most) future git-merge (replacement for
git-pull .) --fetch=<remote>[#<branch>] option.
I'm not that sure about --merge option, but it could be useful, at least
to have current automatic "Merge branch '<branch>' of <URL>" commit message.
--
Jakub Narebski
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:04 ` Jakub Narebski
@ 2006-11-14 22:29 ` Nicolas Pitre
0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 22:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
>
> >> We can always have --merge arguments to git-pull, and --fetch argument to
> >> git-merge.
> >
> > That would be a complete abomination if you want my opinion.
> >
> > Please let git-pull actually pull stuff from a remote place, and
> > git-merge actually merge stuff only. Let's keep simple concepts mapped
> > to simple commands please. Nothing prevents _you_ from scripting more
> > involved operations with a single command of your liking afterwards.
>
> Do we want to abandon completely "single-branch" workflow, where you
> don't use tracking branch, only merge directly into your working branch?
I really think we should. Let's admit it: such a work flow has nothing
to do with the tool. It would certainly be much easier to teach new
users about "this is a read-only view of the remote content that you can
merge into your working branch" than trying to explain why the tool is
so weird for the sake of supporting different work flows directly.
Again I think it is easier to grasp two simple commands than a single
but complex one with multiple ramifications.
> That is the cause to (unused by most) future git-merge (replacement for
> git-pull .) --fetch=<remote>[#<branch>] option.
>
> I'm not that sure about --merge option, but it could be useful, at least
> to have current automatic "Merge branch '<branch>' of <URL>" commit message.
A "remote" branch should obviously have a corresponding URL. So if you
do "git-merge remote" then you may as well prepare a commit message with
that URL given the local name for that branch if you want.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 20:52 ` Nicolas Pitre
2006-11-14 21:01 ` Jakub Narebski
@ 2006-11-14 21:10 ` Carl Worth
2006-11-14 21:30 ` Jakub Narebski
2006-11-14 22:36 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-14 21:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andy Whitcroft, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]
On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
> Even if I have a clear preference for GIT's _technology_, I still think
> that the HG user interface is more convivial. I even been thinking
> about writing something like an hg-like frontend to GIT from time to
> time just so that GIT could then be better compared to (and actually
> just used like) HG.
I've actually been tempted to do the same myself. I really think that
the technology is a more important criterion than the UI so the
imagined hg-on-git interface would be an attempt to get people to look
past the interface differences and look at the technology when
deciding.
But, then, I'd be guilty of creating another cogito, and I just argued
against its existence in a separate thread. So I think we're better
off just fixing the git interface.
> I still think that the GIT user interface sucks in many ways. The
> confusion between pull, fetch and push is still my favorite, along with
> the locale vs remote branch issue. Maybe we'll better handle the branch
> issue eventually,
The --use-separate-remotes thing is technology in the right direction
here. But I think it's another example of very useful stuff being
improperly hidden behind another command-line option. Getting rid of
the "remote-tracking branches" as user-visible branches possible for
committing should be a priority. And that should be the default for
everyone, not just people who happen to clone with this obscure
option.
Similarly, the reflog stuff was often trumpeted in the recent git
vs. bzr debate. Why is that very useful functionality buried in a
config file option and not just stored by default?
> This is really what most people expect from such a command name based
> on obvious historical reasons. The lack of any branch argument to
> git-pull and git-merge could be defined as using the first defined
> remote branch by default.
Once again, there's lots of useful work on "branch configuration" that
allows for commands to be able to get the "right" default repository
for push and pull. I hope that that stuff can be enabled by default
and not require --use-separate-remotes or manual configuration for
people to benefit from it.
I apologize if I sound like I'm ranting here. I love to see the many
good improvements being made to git. It's just that there seems to be
a sort of shyness about new features, (perhaps a fear of changing
existing behavior?). When it improves the user experience, let's make
the improvement the default and not add any more
--make-this-command-do-what-it-really-should-have-always-done
options.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:10 ` Carl Worth
@ 2006-11-14 21:30 ` Jakub Narebski
2006-11-14 21:34 ` Nicolas Pitre
2006-11-14 22:36 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-14 21:30 UTC (permalink / raw)
To: git
The git interface refactoring should be I think the cause for git 2.0.0
release...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:30 ` Jakub Narebski
@ 2006-11-14 21:34 ` Nicolas Pitre
2006-11-14 22:56 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-14 21:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Tue, 14 Nov 2006, Jakub Narebski wrote:
> The git interface refactoring should be I think the cause for git 2.0.0
> release...
Good idea indeed.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:34 ` Nicolas Pitre
@ 2006-11-14 22:56 ` Junio C Hamano
2006-11-15 1:48 ` Nicolas Pitre
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:56 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 14 Nov 2006, Jakub Narebski wrote:
>
>> The git interface refactoring should be I think the cause for git 2.0.0
>> release...
>
> Good idea indeed.
We need to avoid user confusion, so making a command that used
to do one thing to suddenly do something completely different is
a no-no. However, I do not think it needs to wait for 2.0.0.
We can start with a separate namespace (or even a separate
"Improved git UI project") and introduce the "improved UI set"
in 1.5.0 timeframe.
If managed properly, the "improved git UI" can coexist with the
current set of tools and over time we can give an option not to
even install the older Porcelain-ish commands.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:56 ` Junio C Hamano
@ 2006-11-15 1:48 ` Nicolas Pitre
2006-11-15 2:10 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
> >
> >> The git interface refactoring should be I think the cause for git 2.0.0
> >> release...
> >
> > Good idea indeed.
>
> We need to avoid user confusion, so making a command that used
> to do one thing to suddenly do something completely different is
> a no-no. However, I do not think it needs to wait for 2.0.0.
> We can start with a separate namespace (or even a separate
> "Improved git UI project") and introduce the "improved UI set"
> in 1.5.0 timeframe.
Dunno. I feel this is a bit overboard. Actually the naming problem is
rather localized to one command, namely git-pull. In my opinion going
with yet another namespace which would rather add to the confusion not
clear it.
The best way to avoid user confusion is to remove the source of the
confusion not let it live. In other words I think we should _fix_
git-pull instead of replacing it. People are already confused about it
so simply fixing this command will have a net confusion reduction. Yet
we're not talking about "suddenly doing something completely different"
either. If git-pull doesn't merge automatically anymore it is easy to
tell people to use git-merge after a pull.
"You pull the remote changes with 'git-pull upstream,, then you can
merge them in your current branch with 'git-merge upstream'."
Isn't it much simpler to understand (and to teach) that way?
Also I don't think using git-upload and git-download is much better.
This adds yet more commands that do almost the same as existing ones but
with a different name which is yet not necessarily fully adequate. I
for example would think that "download" is more like git-clone than
git-fetch or git-pull.
Let's face it: HG got it right with pull and push and newbies have much
less difficulty grokking it. We screwed it by not using the most
intuitive semantic of a pull and locking the word "pull" away is not the
better solution given all considerations. Why just not admit it and
avoid being different than HG just for the sake of it?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 1:48 ` Nicolas Pitre
@ 2006-11-15 2:10 ` Junio C Hamano
2006-11-15 2:27 ` Michael K. Edwards
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 2:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
> "You pull the remote changes with 'git-pull upstream,, then you can
> merge them in your current branch with 'git-merge upstream'."
>
> Isn't it much simpler to understand (and to teach) that way?
If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.
I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion. But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
That's where my "you download from the upstream and merge" comes
from.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 2:10 ` Junio C Hamano
@ 2006-11-15 2:27 ` Michael K. Edwards
2006-11-15 4:20 ` Nicolas Pitre
2006-11-15 20:12 ` Petr Baudis
2 siblings, 0 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-15 2:27 UTC (permalink / raw)
To: git
I would kind of like to see "git poll" -- visit all remote branches,
fetching objects and tags into the local repository, so that I can
inspect changes off-line and merge, cherry-pick, etc. to my heart's
content. That would fit the platform integrator's workflow nicely --
"git poll" into a tracking tree, do some merges there (such as
backporting a subsystem to a "stable" base kernel), then merge this
backport branch to each platform working copy and cherry-pick other
changes as necessary.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 2:10 ` Junio C Hamano
2006-11-15 2:27 ` Michael K. Edwards
@ 2006-11-15 4:20 ` Nicolas Pitre
2006-11-15 4:58 ` Junio C Hamano
2006-11-15 18:03 ` Linus Torvalds
2006-11-15 20:12 ` Petr Baudis
2 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > "You pull the remote changes with 'git-pull upstream,, then you can
> > merge them in your current branch with 'git-merge upstream'."
> >
> > Isn't it much simpler to understand (and to teach) that way?
>
> If it were "you download the remote changes with 'git download
> upstream' and then merge with 'git merge'", then perhaps, but if
> you used the word "pull" or "fetch", I do not think so.
>
> I would be all for changing the semantics of "pull" from one
> thing to another, if the new semantics were (1) what everybody
> welcomed, (2) what "pull" traditionally meant everywhere else.
> In that case, we have been misusing it to be confusing to
> outsiders and I agree it makes a lot of sense to remove the
> source of confusion. But I do not think CVS nor SVN ever used
> the term, and I was told that BK was what introduced the term,
> and the word meant something different from what you are
> proposing.
>
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.
>
> That's where my "you download from the upstream and merge" comes
> from.
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is. This means that their
definition is becoming rather more relevant with time than what it used
to, and because it is a saner definition than what GIT has for the same
word which HG users really have no issue with, I think we really should
leverage the "common wisdom" and consider aligning ourselves with them
in this case rather than trying to go into a totally different
direction. We simply won't gain anything trying to teach people "a pull
in HG is a download in GIT". If a pull becomes the same thing for both
then it's one less oddball in the GIT interface.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:20 ` Nicolas Pitre
@ 2006-11-15 4:58 ` Junio C Hamano
2006-11-15 18:03 ` Linus Torvalds
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 4:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
> ... We simply won't gain anything trying to teach people "a pull
> in HG is a download in GIT". If a pull becomes the same thing for both
> then it's one less oddball in the GIT interface.
I personally do not have any issue with that, as long as you
would help us convert existing users that what was known as pull
is not available and new pull means fetching only.
If I recall correctly in this thread, you also advocated to
always have tracking branches. I am a bit worried about losing
the promiscuous pull usage, which can easily become a regression
for people like Linus in the integrator role unless done with an
escape hatch.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:20 ` Nicolas Pitre
2006-11-15 4:58 ` Junio C Hamano
@ 2006-11-15 18:03 ` Linus Torvalds
2006-11-15 18:28 ` Jakub Narebski
` (5 more replies)
1 sibling, 6 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 18:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
On Tue, 14 Nov 2006, Nicolas Pitre wrote:
>
> But the fact is that HG (which has a growing crowd of happy campers,
> maybe even larger than the BK crowd now) did work with and got used to a
> sensible definition of what a "pull" is.
Guys, before you start thinking this way, the fact is, there's a lot of
happy git users.
So the reason for using "git pull" is
- bk did it that way, and like it or not, bk was the first usable
distributed system. hg is totally uninteresting.
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
So don't fall for the classic "second system syndrome". The classic reason
for getting the second system wrong is because you focus on the issues
people complain about, and not on the issues that work well (because the
issues that work fine are obviously not getting a lot of attention).
If you think "pull" is confusing, I can guarantee you that _changing_ the
name is a hell of a lot more confusing. In fact, I think a lot of the
confusion comes from cogito, not from git - the fact that cogito used
different names and different syntax was a mistake, I think.
And that '#' for branch naming in particular was (and is) total
braindamage. The native git branch naming convention is just fundamentally
much better, and allows you to very naturally fetch multiple branches at
once, in a way that cogito's syntax does not.
So when I see suggestions of using that brain-damaged cogito syntax as an
"improvement", I know for a fact that somebody hasn't thought things
through, and only thinks it's a better syntax beause of totally bogus
reasons.
I do agree that we probably could/should re-use the "git merge" name. The
current "git merge" is an esoteric internal routine, and I doubt a lot of
people use it as-is. I don't think it would be a mistake to make "git
merge" basically be an alias for "git pull", for example, and I doubt many
people would really even notice.
But the fact is, git isn't really that hard to work out, and the commands
aren't that complicated. There's no reason to rename them. We do have
other problems:
- default branch selection for merging is broken (it should definitely
take the current branch into account). When I do "git pull" with no
branch specification, and I happen to be on a branch that is associated
with something else than "master" in the remote, I shouldn't merge with
master.
- I agree that having to create temporary branches to just look at a tag
that you don't want to actually develop on is just unnecessarily
bothersome.
But trying to rename "pull" (or the "git" name itself) is just going to
cause more confusion than you fix.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
@ 2006-11-15 18:28 ` Jakub Narebski
2006-11-15 20:31 ` Josef Weidendorfer
2006-11-15 18:43 ` Nicolas Pitre
` (4 subsequent siblings)
5 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 18:28 UTC (permalink / raw)
To: git
Linus Torvalds wrote:
> But the fact is, git isn't really that hard to work out, and the commands
> aren't that complicated. There's no reason to rename them. We do have
> other problems:
>
> - default branch selection for merging is broken (it should definitely
> take the current branch into account). When I do "git pull" with no
> branch specification, and I happen to be on a branch that is associated
> with something else than "master" in the remote, I shouldn't merge with
> master.
This problem is _slightly_ migitated by branch.<name>.merge config variable.
Slightly because you have to specify branch to merge, instead of forbidding
merge if you are not on specific branch (and you don't override it).
> - I agree that having to create temporary branches to just look at a tag
> that you don't want to actually develop on is just unnecessarily
> bothersome.
Agreed.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:28 ` Jakub Narebski
@ 2006-11-15 20:31 ` Josef Weidendorfer
2006-11-15 20:35 ` Petr Baudis
0 siblings, 1 reply; 601+ messages in thread
From: Josef Weidendorfer @ 2006-11-15 20:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Linus Torvalds, Nicolas Pitre, Junio C Hamano
On Wednesday 15 November 2006 19:28, you wrote:
> Linus Torvalds wrote:
>
> > But the fact is, git isn't really that hard to work out, and the commands
> > aren't that complicated. There's no reason to rename them. We do have
> > other problems:
> >
> > - default branch selection for merging is broken (it should definitely
> > take the current branch into account). When I do "git pull" with no
> > branch specification, and I happen to be on a branch that is associated
> > with something else than "master" in the remote, I shouldn't merge with
> > master.
>
> This problem is _slightly_ migitated by branch.<name>.merge config variable.
> Slightly because you have to specify branch to merge, instead of forbidding
> merge if you are not on specific branch (and you don't override it).
We should change this.
The problem is that whatever is the first Pull line in remotes config gets
merged by default into current branch, which most often is not the right
thing to do.
Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.
Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?
This even could be written by default in git-clone somewhere in the future,
and we suddenly get the behavior of pull being symmetric to push - at least
by default. And still, it is fully compatible to existing repositories.
To make pull do the right thing, we _have_ to configure branch.<name>.merge
whenever we create a new branch (which matters for git-clone, too).
Josef
>
> > - I agree that having to create temporary branches to just look at a tag
> > that you don't want to actually develop on is just unnecessarily
> > bothersome.
>
> Agreed.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:31 ` Josef Weidendorfer
@ 2006-11-15 20:35 ` Petr Baudis
2006-11-15 21:12 ` Josef Weidendorfer
0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:35 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre, Junio C Hamano
On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> Often, I find myself doing "git branch" just to make sure that I am on
> "master", so that a following pull does not do a bogus merge.
>
> Can we please disable this behavior, e.g. by allowing a fake first
> Pull line like "Pull: (not-for-merge)" to prohibit any merge?
Wait, if you don't want pull to merge, why do you pull and not fetch?
(Disclaimer: I'm not intimately familiar with git pull/fetch and I
didn't read the whole thread yet.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:35 ` Petr Baudis
@ 2006-11-15 21:12 ` Josef Weidendorfer
2006-11-15 21:31 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Josef Weidendorfer @ 2006-11-15 21:12 UTC (permalink / raw)
To: Petr Baudis
Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre, Junio C Hamano
On Wednesday 15 November 2006 21:35, Petr Baudis wrote:
> On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> > Often, I find myself doing "git branch" just to make sure that I am on
> > "master", so that a following pull does not do a bogus merge.
> >
> > Can we please disable this behavior, e.g. by allowing a fake first
> > Pull line like "Pull: (not-for-merge)" to prohibit any merge?
>
> Wait, if you don't want pull to merge, why do you pull and not fetch?
I am not really opposed to pull doing a merge. It only should work in
a useful way: ie. only do the merge of updated origin branch when
current branch is master (given "Pull: master:origin").
I want "git pull" being harmless if I find myself accidently on a
branch != master. I always can do "git checkout master; git pull . origin"
afterwards.
For this to work, I currently need to specify a "branch.<name>.merge"
config for _every_ branch I have, as otherwise I get this bogus pull
merge behavior. This is not needed if there was a way to configure no
merge at all as default pull behavior.
I just noted that allowing such a config option would be kind of a
working compromise for all the people which want
pull to be the opposite of push.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:12 ` Josef Weidendorfer
@ 2006-11-15 21:31 ` Linus Torvalds
0 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 21:31 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Petr Baudis, Jakub Narebski, git, Nicolas Pitre, Junio C Hamano
On Wed, 15 Nov 2006, Josef Weidendorfer wrote:
>
> I am not really opposed to pull doing a merge. It only should work in
> a useful way: ie. only do the merge of updated origin branch when
> current branch is master (given "Pull: master:origin").
I absolutely agree.
We should _only_ use the default head when pulling from the default head
("master"). If we don't pull from within the default branch, we should
either require an explicit head _or_ we should require that an explicit
mapping has been set up in .git/config or in .git/remotes/..
So doing a "git pull" from any other branch than "master" should probably
by default say "which branch do you want to pull from today"?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
2006-11-15 18:28 ` Jakub Narebski
@ 2006-11-15 18:43 ` Nicolas Pitre
2006-11-15 18:49 ` Shawn Pearce
2006-11-15 18:58 ` Andy Parkins
` (3 subsequent siblings)
5 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Tue, 14 Nov 2006, Nicolas Pitre wrote:
> >
> > But the fact is that HG (which has a growing crowd of happy campers,
> > maybe even larger than the BK crowd now) did work with and got used to a
> > sensible definition of what a "pull" is.
>
> Guys, before you start thinking this way, the fact is, there's a lot of
> happy git users.
>
> So the reason for using "git pull" is
>
> - bk did it that way, and like it or not, bk was the first usable
> distributed system. hg is totally uninteresting.
>
> - git itself has now done it that way for the last 18 months, and the
> fact is, the people _complaining_ are a small subset of the people who
> actually use git on a daily basis and don't complain.
Those arguments are somewhat flawed. If we stick to "BK did it that way
and it was first", then following that logic we would also carry a lot
of CVS baggage because "CVS did it that way, and it was the most
successful of its kind". Still, we decided not to follow CVS nor BK in
many ways already.
As for the fraction of people complaining being a small fraction of
current GIT users: that is easily explainable by the fact that most
people who would have grown the complainers group are simply not GIT
users anymore since they were turned away by GIT's current user
interface issues. The only complainers remaining are those who see
value in the GIT technology but who would like to bring more
intuitiveness to the GIT interface instead of going for the alternative
technology. And those kind of people are always few.
> So don't fall for the classic "second system syndrome". The classic reason
> for getting the second system wrong is because you focus on the issues
> people complain about, and not on the issues that work well (because the
> issues that work fine are obviously not getting a lot of attention).
The counter part of that is the possibility to fall for the "ivory tower
syndrome" where seasoned GIT users feel they are well satisfied with
what is currently available and unwilling to consider changes that would
reduce the barrier to entry for new users... simply because they are so
used to the way things work that they can't see why others have problems
with it.
> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing.
Agreed. This is why the current discussion led to a proposition that
allows for "pull" to remain as is but to have a "get" version that would
be the alternate (saner) version.
> In fact, I think a lot of the
> confusion comes from cogito, not from git - the fact that cogito used
> different names and different syntax was a mistake, I think.
>
> And that '#' for branch naming in particular was (and is) total
> braindamage. The native git branch naming convention is just fundamentally
> much better, and allows you to very naturally fetch multiple branches at
> once, in a way that cogito's syntax does not.
>
> So when I see suggestions of using that brain-damaged cogito syntax as an
> "improvement", I know for a fact that somebody hasn't thought things
> through, and only thinks it's a better syntax beause of totally bogus
> reasons.
Do you have comments on my proposed syntax (that would be implemented
with a git-get command) which I think doesn't really look like cogito?
> I do agree that we probably could/should re-use the "git merge" name. The
> current "git merge" is an esoteric internal routine, and I doubt a lot of
> people use it as-is. I don't think it would be a mistake to make "git
> merge" basically be an alias for "git pull", for example, and I doubt many
> people would really even notice.
Agreed.
> But the fact is, git isn't really that hard to work out, and the commands
> aren't that complicated.
I agree with you in general, except for the "pull" behavior which is
really really odd. Maybe it made sense in the BK context, maybe it is
fine _once_ you get used to it, but otherwise it is really overloaded.
> But trying to rename "pull" (or the "git" name itself) is just going to
> cause more confusion than you fix.
Agreed again.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:43 ` Nicolas Pitre
@ 2006-11-15 18:49 ` Shawn Pearce
2006-11-15 19:05 ` Marko Macek
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 18:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, git
Nicolas Pitre <nico@cam.org> wrote:
> As for the fraction of people complaining being a small fraction of
> current GIT users: that is easily explainable by the fact that most
> people who would have grown the complainers group are simply not GIT
> users anymore since they were turned away by GIT's current user
> interface issues. The only complainers remaining are those who see
> value in the GIT technology but who would like to bring more
> intuitiveness to the GIT interface instead of going for the alternative
> technology. And those kind of people are always few.
Or they are by proxy.
*I* don't see that much of a problem with git pull; I can use it
without trouble at this point. But I find it difficult to teach
to others.
My complaints about git pull/fetch/push are by proxy for about 10
other users who aren't on the mailing list but whom I interact with
through Git. They don't like pull/fetch/push very much.
So count my complaints 10 times. :)
Ok, that's still a drop in the bucket of current Git users.
But still, I'm sure there are others. I think Carl was recently
talking about complaints from some Fedora folks...
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:49 ` Shawn Pearce
@ 2006-11-15 19:05 ` Marko Macek
2006-11-15 20:41 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Marko Macek @ 2006-11-15 19:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Junio C Hamano, git, cworth, pasky
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> As for the fraction of people complaining being a small fraction of
>> current GIT users: that is easily explainable by the fact that most
>> people who would have grown the complainers group are simply not GIT
>> users anymore since they were turned away by GIT's current user
>> interface issues. The only complainers remaining are those who see
>> value in the GIT technology but who would like to bring more
>> intuitiveness to the GIT interface instead of going for the alternative
>> technology. And those kind of people are always few.
>
> Or they are by proxy.
>
> *I* don't see that much of a problem with git pull; I can use it
> without trouble at this point. But I find it difficult to teach
> to others.
>
> My complaints about git pull/fetch/push are by proxy for about 10
> other users who aren't on the mailing list but whom I interact with
> through Git. They don't like pull/fetch/push very much.
>
> So count my complaints 10 times. :)
>
> Ok, that's still a drop in the bucket of current Git users.
> But still, I'm sure there are others. I think Carl was recently
> talking about complaints from some Fedora folks...
Agreed. Personally, the first thing that I notice when trying to switch
from Subversion to git is the behavior of 'index', mainly in git-diff, git-status and
git-commit.
For people switching from CVS and SVN it would be much better if the index was hidden
behind the scenes by using different defaults:
git-commit -a
git-status -a
git-diff HEAD
BTW, currently there's a minor bug: git-diff HEAD doesn't work before you
make the first commit. Perhaps this should be special cased.
I could personally get used to this, but I'd surely get blank
stares from people when teaching them the difference.
I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
(which is very confusing for someone coming to _git_ home page, trying to learn git).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:05 ` Marko Macek
@ 2006-11-15 20:41 ` Junio C Hamano
2006-11-15 22:07 ` Shawn Pearce
2006-11-16 6:07 ` Marko Macek
2006-11-15 22:28 ` Sean
[not found] ` <20061115172834.0a328154.seanlkml@sympatico.ca>
2 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 20:41 UTC (permalink / raw)
To: Marko Macek; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky
Marko Macek <marko.macek@gmx.net> writes:
> For people switching from CVS and SVN it would be much better if the
> index was hidden behind the scenes by using different defaults:
>
> git-commit -a
> git-status -a
> git-diff HEAD
>
> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
> you make the first commit. Perhaps this should be special cased.
That's only a _bug_ in your implementation of the synonym for
"svn diff" which blindly used "git diff HEAD".
"git diff HEAD" is not a synonym for "svn diff" when HEAD does
not exist yet, because you are asking "please give me a diff
between the tree in the HEAD commit and my working tree files
through the index". So if you are doing "git-svnish-diff"
Porcelain script, it should notice that HEAD does not exist yet
and take an appropriate action. We do something similar in
git-status; the porcelain notices and acts differently when HEAD
is not there yet.
This "there is no HEAD yet" is not related to the index, but I
am skeptical about trying to hide the index from the end user.
You can make some things map more naturally to systems like SVN
and CVS than other things. For example, Nico's proposal to
always use remote tracking branches and defaulting to use
refs/remotes/ would be a way to match UI of pull/push to another
existing system and that would work well (I am not agreeing to
the change to make 'pull' not to do the merge which would break
existing users -- I am just saying that the result would be self
consistent). But things that have difference at the concept
level, I suspect no clever mapping to hide the differences would
work well.
The index is quite central to the way git works at the concept
level, and I think it is doing disservice to the end user to try
hiding it forever from them and failing to do so, rather than
being honest and teaching them the concept upfront.
But me thinking so does not necessarily mean you are forbidden
from trying. Your efforts may result in a system where the
index is totally invisible and the end user never has to know
about it.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:41 ` Junio C Hamano
@ 2006-11-15 22:07 ` Shawn Pearce
2006-11-16 6:07 ` Marko Macek
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marko Macek, Linus Torvalds, git, cworth, pasky
Junio C Hamano <junkio@cox.net> wrote:
> The index is quite central to the way git works at the concept
> level, and I think it is doing disservice to the end user to try
> hiding it forever from them and failing to do so, rather than
> being honest and teaching them the concept upfront.
>
> But me thinking so does not necessarily mean you are forbidden
> from trying. Your efforts may result in a system where the
> index is totally invisible and the end user never has to know
> about it.
I agree with what you are saying about the index.
But in git-gui I found myself writing code on Monday which tries to
hide the index from the user unless he/she requested that the index
be made visible.
The reason is there are some users who I'd like to give git-gui to
who I'm not sure I trust to make sure their index is in sync with
their working directory before they commit. In some cases I'm lucky
that the user even knows what directory their file is stored in. :-(
Yes, there really are computer users who are afraid of directories
and command lines.
I probably could try to teach them to make sure the final file
is included in the index before committing, but I think that for
most of them they would find this to be just another couple of
mouse clicks they have to perform before every commit, meaning its
something that the #$@!*@!*@$# tool should just do for them.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:41 ` Junio C Hamano
2006-11-15 22:07 ` Shawn Pearce
@ 2006-11-16 6:07 ` Marko Macek
2006-11-16 10:36 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Marko Macek @ 2006-11-16 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Linus Torvalds, git, cworth, pasky
Junio C Hamano wrote:
> Marko Macek <marko.macek@gmx.net> writes:
>
>> For people switching from CVS and SVN it would be much better if the
>> index was hidden behind the scenes by using different defaults:
>>
>> git-commit -a
>> git-status -a
>> git-diff HEAD
>>
>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>> you make the first commit. Perhaps this should be special cased.
>
> That's only a _bug_ in your implementation of the synonym for
> "svn diff" which blindly used "git diff HEAD".
My "implementation" is taken from git-diff man page. It seems obvious
that the situation before the first commit is just a special case if
we consider git-diff to be Porcelain (which I do).
> This "there is no HEAD yet" is not related to the index, but I
I agree, this is a separate issue.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 6:07 ` Marko Macek
@ 2006-11-16 10:36 ` Junio C Hamano
2006-11-17 13:45 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:36 UTC (permalink / raw)
To: Marko Macek; +Cc: git
Marko Macek <marko.macek@gmx.net> writes:
>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>>> you make the first commit. Perhaps this should be special cased.
>>
>> That's only a _bug_ in your implementation of the synonym for
>> "svn diff" which blindly used "git diff HEAD".
>
> My "implementation" is taken from git-diff man page. It seems obvious
> that the situation before the first commit is just a special case if
> we consider git-diff to be Porcelain (which I do).
Yes, "git diff" is a Porcelain. No question about it.
I do not consider the current behaviour of "git diff HEAD" that
complains instead of giving runs of "foo is a new file and no
diff is available for it" a bug; you asked for diff from some
commit but the commit you gave was bogus (does not exist yet).
But if you feel strongly about it, it should be trivial to
special case the yet-to-be-born HEAD case and run the
equilvalent of:
git ls-files | sed -e 's/$/ is a new file, no diff is available./'
in such a case. Or you could even go fancier and do an
equivalent of:
git ls-files |
while read path
do
l=`wc -l <"$path"`
echo "diff --git a/$path b/$path"
echo "--- a/$path"
echo "--- b/$path"
echo "@@ -0,0 +1,$l @@"
sed -e 's/^/+/' <"$path"
done
and you can claim that it makes it consistent with the case
where you already have commits.
But I happen to think that consistency is only of academic
interest. After all, how often would one create a true "root"
commit? We are not talking about creating a new repository that
starts its life as a clone of something else, but a truly empty
one in which the initial commit is made. And how often would
one want to view "diff" from void while preparing for that
initial commit? Both that low frequency _and_ general
uselessness of the output from either of the above shell
scripts, would it be worth "fixing" it?
I do not think it adds any real practical value, and does not
even have much to do with being user friendly. I would put it
in the "when somebody is really bored and has nothing better to
do, then this _could_ be done" category.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 10:36 ` Junio C Hamano
@ 2006-11-17 13:45 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:45 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Marko Macek <marko.macek@gmx.net> writes:
>
>>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>>>> you make the first commit. Perhaps this should be special cased.
>>>
>>> That's only a _bug_ in your implementation of the synonym for
>>> "svn diff" which blindly used "git diff HEAD".
>>
>> My "implementation" is taken from git-diff man page. It seems obvious
>> that the situation before the first commit is just a special case if
>> we consider git-diff to be Porcelain (which I do).
>
> Yes, "git diff" is a Porcelain. No question about it.
>
> I do not consider the current behaviour of "git diff HEAD" that
> complains instead of giving runs of "foo is a new file and no
> diff is available for it" a bug; you asked for diff from some
> commit but the commit you gave was bogus (does not exist yet).
git diff --root HEAD, perhaps?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:05 ` Marko Macek
2006-11-15 20:41 ` Junio C Hamano
@ 2006-11-15 22:28 ` Sean
[not found] ` <20061115172834.0a328154.seanlkml@sympatico.ca>
2 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 22:28 UTC (permalink / raw)
To: Marko Macek
Cc: Shawn Pearce, Linus Torvalds, Junio C Hamano, git, cworth, pasky
On Wed, 15 Nov 2006 20:05:27 +0100
Marko Macek <marko.macek@gmx.net> wrote:
> I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
> (which is very confusing for someone coming to _git_ home page, trying to learn git).
IMHO this is really bad. Pasky runs the Git web site and feels
that Cogito comes hand in hand with Git. When I asked him about
it he mentioned that Junio had approved. But it's very confusing
to click a link that purports to show you how to use Git and get
shown a bunch of Cogito stuff.
Git is confusing enough for new users without "Git" and "Cogito"
being mixed without comment on the Git webpage. At the very
least, the links should be changed to "Cogito for CVS/SVN users".
^ permalink raw reply [flat|nested] 601+ messages in thread
[parent not found: <20061115172834.0a328154.seanlkml@sympatico.ca>]
* Re: Cleaning up git user-interface warts
[not found] ` <20061115172834.0a328154.seanlkml@sympatico.ca>
@ 2006-11-16 3:07 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 3:07 UTC (permalink / raw)
To: Sean
Cc: Marko Macek, Shawn Pearce, Linus Torvalds, Junio C Hamano, git, cworth
On Wed, Nov 15, 2006 at 11:28:34PM CET, Sean wrote:
> Git is confusing enough for new users without "Git" and "Cogito"
> being mixed without comment on the Git webpage. At the very
> least, the links should be changed to "Cogito for CVS/SVN users".
It's not being mixed without comment, in the very first paragraph I'm
trying to explain what the difference is and why is Cogito used for
introduction to Git. I've tried to clear it up even more now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
2006-11-15 18:28 ` Jakub Narebski
2006-11-15 18:43 ` Nicolas Pitre
@ 2006-11-15 18:58 ` Andy Parkins
2006-11-15 19:18 ` Linus Torvalds
2006-11-15 19:32 ` Junio C Hamano
2006-11-16 1:14 ` Theodore Tso
` (2 subsequent siblings)
5 siblings, 2 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 18:58 UTC (permalink / raw)
To: git
On Wednesday 2006, November 15 18:03, Linus Torvalds wrote:
> Guys, before you start thinking this way, the fact is, there's a lot of
> happy git users.
I'm a happy user, doesn't mean I wouldn't like changes. In fact, by that
argument, that there are happy users means that there is no need to ever make
changes.
> - git itself has now done it that way for the last 18 months, and the
> fact is, the people _complaining_ are a small subset of the people who
> actually use git on a daily basis and don't complain.
That's awfully like the argument I hear off my bank whenever I complain to
them too - "well lots of other people don't complain so we must be right".
The people who complain are a subset of the people who have complaints. I
don't think never changing is a good argument - leaving aside the actual
changes under discussion - in another 18 months lets say there are double the
number of git users, and 18 months after that double again - in that case the
potential new users needs outweigh the current users needs.
> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing. In fact, I think a lot of the
> But the fact is, git isn't really that hard to work out, and the commands
On the one hand you're arguing that git syntax is easy to learn, and on the
other that no one will be able to learn a new syntax just as easily.
> aren't that complicated. There's no reason to rename them. We do have
> other problems:
That there are other problems doesn't negate these problems.
> But trying to rename "pull" (or the "git" name itself) is just going to
> cause more confusion than you fix.
I don't think so. Mainly because the proposed new git pull would be a subset
of the existing git pull. It's not changing function, it's just reducing in
function.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:58 ` Andy Parkins
@ 2006-11-15 19:18 ` Linus Torvalds
2006-11-15 19:39 ` Michael K. Edwards
2006-11-16 1:40 ` Anand Kumria
2006-11-15 19:32 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 19:18 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Wed, 15 Nov 2006, Andy Parkins wrote:
>
> On the one hand you're arguing that git syntax is easy to learn, and on the
> other that no one will be able to learn a new syntax just as easily.
I'm saying that people who are new to git will _have_ to learn new
concepts ANYWAY.
I don't think the naming is the hard part.
The fact is, git is one of the very few (essentially _only_) SCM's that
make it very clear that all real operations are local and that if you want
to work with other repositories, you have to "fetch" those into local
branches first. The fact that "pull" exists at all is really just
shorthand.
If people have trouble explaining this to others, and have trouble
grasping "pull", then I will bet that the _real_ issue has nothing at all
to do with naming at all, and the real issue is that people are being
_taught_ the concepts in the wrong order.
Before you learn "pull", you should learn "fetch". Don't even _mention_
"pull" until the person got what "fetch" means. Because the fact is,
"fetch" is really the much more fundamental operation, and once you
really understand what "fetch" does, "pull" is obvious.
So I'll argue that the problem isn't naming, the "problem" is really that
git has a few fundamnetal concepts that people aren't used to. The most
fundamnetal of those is the notion of the local branch-space. EVERY other
(broken) SCM has branches as being some kind of totally idiotic separate
subdirectories, or doesn't really support branches at all (ie neither BK
nor CVS really support "branches" - even if a concept of that name exists
in CVS, it has nothing at all in common with the git model of branches).
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:18 ` Linus Torvalds
@ 2006-11-15 19:39 ` Michael K. Edwards
2006-11-15 20:09 ` Linus Torvalds
2006-11-16 1:40 ` Anand Kumria
1 sibling, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-15 19:39 UTC (permalink / raw)
To: git
On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> But once you understand branches, and understand "fetch" (and it really
> isn't _that_ complicated: fetch really does exactly what the name says, so
> if you understand local branches, you will understand "fetch"), then it's
> a much smaller step to explain "pull = fetch + merge".
>
> But I bet people don't teach it that way. They _start_ by teaching "pull".
> Right?
"git fetch" is certainly the right thing for the platform integration
role, in which one is trying to maintain a series of integration
branches which track the bleeding edge of some subsystems while
keeping the core stable on each branch. This is not as impossible as
people make it out to be, but there certainly isn't much place for
automatic merges to _persistent_ branches.
It's fundamentally a backporting and cherry-picking effort, and the
git workflow puts it where it belongs: in the local repository, where
_transient_ branches can and should be created and destroyed casually
to track exploratory efforts. These may include automatic merges and
even cruder techniques (git diff, hack on patch, apply patch). Once
you figure out which bits you actually want to backport, you go back
to a fresh branch and cherry-pick the same bits with the tool instead
of manually, so that there is less noise in future merges. When
you've tested a little, you merge this branch to the persistent branch
that other repositories track.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:39 ` Michael K. Edwards
@ 2006-11-15 20:09 ` Linus Torvalds
2006-11-15 20:21 ` Nicolas Pitre
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:09 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
On Wed, 15 Nov 2006, Michael K. Edwards wrote:
> >
> > But I bet people don't teach it that way. They _start_ by teaching "pull".
> > Right?
>
> "git fetch" is certainly the right thing for the platform integration
> role
I'm saying that even if you _never_ end up using "git fetch" ever again
(because in practice you always want to do a "fetch + merge == pull"),
people who teach others the concepts and usage of git should probably
start by talking about "git fetch".
Then, when the user says (and he obviously will say this) "but I don't
want to just fetch the other persons work into some local branch, I want
to actually get it into _my_ branch", you say "Ahhah!" and talk about how
"pull" is a shorthand for first fetching and then merging the result into
the current branch.
See? Once you explain "fetch" to somebody, I can pretty much guarantee
that they'll explain "pull" to themselves without you having to even work
at it. And then they'll probably happily use "pull" ever after, and never
worry about fetch, but now they'll understand the _concepts_.
It's only if you start the other way around that "pull" vs "fetch" vs
"push" become confusing. If you _start_ by explaining branches (and you
might use "gitk --all" on a small project as a visualization tool),
suddenly the concepts aren't all that complicated.
Sure, then you have to remember two words ("pull" vs "fetch"), but I'm
pretty sure that the thing that makes people confused is not the words
themselves, but their lack of understanding of the concepts behind them.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:09 ` Linus Torvalds
@ 2006-11-15 20:21 ` Nicolas Pitre
2006-11-15 20:40 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael K. Edwards, git
On Wed, 15 Nov 2006, Linus Torvalds wrote:
> I'm saying that even if you _never_ end up using "git fetch" ever again
> (because in practice you always want to do a "fetch + merge == pull"),
> people who teach others the concepts and usage of git should probably
> start by talking about "git fetch".
>
> Then, when the user says (and he obviously will say this) "but I don't
> want to just fetch the other persons work into some local branch, I want
> to actually get it into _my_ branch", you say "Ahhah!" and talk about how
> "pull" is a shorthand for first fetching and then merging the result into
> the current branch.
Actually I believe it would make things even clearer if "merge" was
taught at that point. Only when the user is comfortable with the
separate notions of fetching and merging might the pull shorthand
possibly be mentioned.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:21 ` Nicolas Pitre
@ 2006-11-15 20:40 ` Linus Torvalds
2006-11-15 21:08 ` Carl Worth
2006-11-16 4:26 ` Theodore Tso
0 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Michael K. Edwards, git
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> Actually I believe it would make things even clearer if "merge" was
> taught at that point. Only when the user is comfortable with the
> separate notions of fetching and merging might the pull shorthand
> possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
People kind of expect merging to be hard, but I think it's because CVS et
al have tought people that merging is _painful_. I don't think it's a very
complicated concept per se, especially if you have explained branches with
gitk already.
But yes, the order should be:
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
(b) once you've explained branches, the notion of "merge" comes next, and
I _think_ that is very obvious. This is where UI issues come in,
because "git merge" is really a totally internal program with a
pretty horrid UI, but I think we could fix the syntax, and even with
the current syntax you can really just gloss it over, because nobody
is really going to care.
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
I think I saw that particular discussion on #git: somebody didn't expect
"git pull . branch" to be the way to merge. And again, I think it's
not _really_ because "pull" is hard to understand, it's because people
haven't been walked through the thing in this way.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
See? Explain it that way: "pull" really is simple. By using "pull", you
don't have to learn about "merge" syntax. You -can- use "merge" as a
separate program if you want to, but the syntax isn't very nice, exactly
because you're not really expected to.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
If you don't understand local branches, you'll never understand git usage.
And once you _do_ understand local branches, "fetch" vs "pull" actually is
rather simple.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:40 ` Linus Torvalds
@ 2006-11-15 21:08 ` Carl Worth
2006-11-15 21:31 ` Junio C Hamano
` (2 more replies)
2006-11-16 4:26 ` Theodore Tso
1 sibling, 3 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 21:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git
[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]
On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > Actually I believe it would make things even clearer if "merge" was
> > taught at that point. Only when the user is comfortable with the
> > separate notions of fetching and merging might the pull shorthand
> > possibly be mentioned.
>
> I agree. I just expect that "merge" is such a simple concept that it
> doesn't really need a whole lot of explaining.
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
So there's this goofy circular notion that people end up with
mentally. If we fix it so that a local merge really is performed with
"git merge <branch>" instead of "git pull . <branch>" then teaching
pull=fetch+merge really is a lot easier.
In the meantime, pull would still be useless to me, I think. But maybe
that's just the "default branch to merge" selection being broken. If
that were fixed, maybe I would start using pull.
> (a) explain what "branches" mean in git (and in that situation, "fetch"
> is very natural - I think fetching itself is probably easier to
> explain than "branches" are).
There's a piece missing here, namely the mapping between remote and
local branch names and any notion of "tracking branches". I think a
sane story for that is still being invented, (or if it exists now, I
haven't seen it yet).
> (c) once "fetching branches" and "merging" have been explained, "pull" is
> really pretty damn trivial, and in fact, if you then explain that
> it's just easier to do "git pull . branchname" than to use "git
> merge", I think people may just even agree with you.
Well, they get pretty darn confused at this point, in my experience.
> Once you understand local branches, fetching and merging, it's actually
> _easier_ to explain why we merge even local branches with "git pull .":
> you just tell them that this way you can use the same command regardless
> of whether you're merging something local or something remote. Again, if
> it's explained that way, I bet a lot of people react with "ahh, that's
> clever", and _like_ the fact that they only really need to learn _one_
> command, instead of learning two.
No. It's really, really broken to use "pull ." for local merging. Not
a feature at all. We just got done establishing that pull is a
shorthand for doing fetch+merge, so reusing it when there is _no_
fetch at all is insane.
You just established quite clearly hat git has a huge advantge over
all other systems by having a model that everything is fetched in
and then worked with locally. I agree that this is a major
selling-point of git, and I'm also baffled that systems like bzr and
hg try so hard to push every branch into a separate repository.
But I think that git's "work with everything locally" story is undercut
a bit by regular usage being to use a transfer-inducing command like
"pull" for a totally local merge.
Anyway, I think we all agree that we'd really rather have "git merge
<branch>" be usable for local merges, so let's get that in place and
users can pick whichever they like.
> But the real issue here is to explain local branches. I will happily admit
> that local branches are very VERY different from just about any other SCM,
> but I also claim that git is just much BETTER than other SCM's in this
> respect.
Totally agree.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:08 ` Carl Worth
@ 2006-11-15 21:31 ` Junio C Hamano
2006-11-15 21:40 ` Nicolas Pitre
2006-11-15 21:45 ` Linus Torvalds
2006-11-21 13:25 ` Jerome Lovy
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:31 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, Linus Torvalds, git
Carl Worth <cworth@cworth.org> writes:
> So there's this goofy circular notion that people end up with
> If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.
I am wondering if that could be "git merge <committish>..."
instead. I do not care too much about the ... part (i.e. an
Octopus), but I often find myself doing:
git checkout next
git merge "Merge early part of branch 'foo'" HEAD foo~3
when earlier part of "foo" topic are worthy to be in 'next' but
not the later ones.
> In the meantime, pull would still be useless to me, I think. But maybe
> that's just the "default branch to merge" selection being broken.
Have you looked into per-branch configuration for default merge
source recently? It might not be documented well enough,
though, because I do not use it myself, but you should be able
to improve on that (meaning both documentation and setting up
the defaults upon cloning and fetching).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:31 ` Junio C Hamano
@ 2006-11-15 21:40 ` Nicolas Pitre
2006-11-15 21:52 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, Michael K. Edwards, Linus Torvalds, git
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> I am wondering if that could be "git merge <committish>..."
> instead. I do not care too much about the ... part (i.e. an
> Octopus), but I often find myself doing:
>
> git checkout next
> git merge "Merge early part of branch 'foo'" HEAD foo~3
>
> when earlier part of "foo" topic are worthy to be in 'next' but
> not the later ones.
Indeed !
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:40 ` Nicolas Pitre
@ 2006-11-15 21:52 ` Junio C Hamano
2006-11-15 21:59 ` Nicolas Pitre
2006-11-17 12:20 ` Karl Hasselström
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
>> I am wondering if that could be "git merge <committish>..."
>> instead. I do not care too much about the ... part (i.e. an
>> Octopus), but I often find myself doing:
>>
>> git checkout next
>> git merge "Merge early part of branch 'foo'" HEAD foo~3
>>
>> when earlier part of "foo" topic are worthy to be in 'next' but
>> not the later ones.
>
> Indeed !
Indeed, what?
That means that updated "git merge" (not the current one) would
not be able to assume it's parameter is a branch name, and still
has to come up with the merge message "Merge <branch>".
Merging only within the local branch namespace already has the
problem you need to solve to come up with a nicely formatted
"Merge <branch> of <remote repository>" some way. I am not
saying that this is unsolvable (you can look at remotes/ files
to see what remote tracking branch the branch is about), but
something you need to keep in mind when implementing the
improved "git merge".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:52 ` Junio C Hamano
@ 2006-11-15 21:59 ` Nicolas Pitre
2006-11-17 12:20 ` Karl Hasselström
1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Wed, 15 Nov 2006, Junio C Hamano wrote:
> >
> >> I am wondering if that could be "git merge <committish>..."
> >> instead. I do not care too much about the ... part (i.e. an
> >> Octopus), but I often find myself doing:
> >>
> >> git checkout next
> >> git merge "Merge early part of branch 'foo'" HEAD foo~3
> >>
> >> when earlier part of "foo" topic are worthy to be in 'next' but
> >> not the later ones.
> >
> > Indeed !
>
> Indeed, what?
What you propose would be excellent indeed.
> That means that updated "git merge" (not the current one) would
> not be able to assume it's parameter is a branch name, and still
> has to come up with the merge message "Merge <branch>".
>
> Merging only within the local branch namespace already has the
> problem you need to solve to come up with a nicely formatted
> "Merge <branch> of <remote repository>" some way. I am not
> saying that this is unsolvable (you can look at remotes/ files
> to see what remote tracking branch the branch is about), but
> something you need to keep in mind when implementing the
> improved "git merge".
Right. But that is an _implementation_ detail, not a usability issue.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:52 ` Junio C Hamano
2006-11-15 21:59 ` Nicolas Pitre
@ 2006-11-17 12:20 ` Karl Hasselström
1 sibling, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-17 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
On 2006-11-15 13:52:47 -0800, Junio C Hamano wrote:
> That means that updated "git merge" (not the current one) would not
> be able to assume it's parameter is a branch name, and still has to
> come up with the merge message "Merge <branch>".
Often, it would be a branch or a tag, so no problem there. For commits
in general, it should not be hard to compute the set of branches and
tags the commit is part of, and in the (probably) common case where
this set has exactly one element, the problem is solved. For the
remaining cases, it should not be too horrible to ask the user to
describe what is being merged.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:08 ` Carl Worth
2006-11-15 21:31 ` Junio C Hamano
@ 2006-11-15 21:45 ` Linus Torvalds
2006-11-15 22:52 ` Carl Worth
2006-11-21 13:25 ` Jerome Lovy
2 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 21:45 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Michael K. Edwards, git
On Wed, 15 Nov 2006, Carl Worth wrote:
>
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
>
> pull = fetch + merge
>
> But then shortly after I have to teach an interface notion:
>
> merge = pull .
This is why I would suggest teaching the _concept_ of the "merge", and not
the actual command.
I don't think you should basically ever use the "git merge" command
itself, not in teaching, and not in real life. So after talking about
branches and having taught people to use "git fetch", the next stage is
not so much to teach people to use "git merge", but to explain to them the
_concept_ of merging.
I really think that's a fairly quick thing, partly exactly _because_ you
shouldn't at that point need to worry about syntax or details or anything
like that at all. You just tell them that there's a notion of "merging"
two branches by joining them together and havign the result have the
changes from both branches. So it's a _conceptual_ issue, and that's why I
said I think you should just totally gloss over the whole issue of "git
merge" syntax.
Once you've explained the _concept_ of merging, you then introduce the
command to actually _execute_ the merge: it's "git pull".
See? No circular thinking at all. One is a _concept_ ("join two branches
together by including both in the result") and the other is a command
("pull will fetch the remote data if any, and merge it into the current
branch").
If you explain it that way, then _obviously_ if you don't need to fetch
any remote data, doing "git pull . xyzzy" will merge the local branch
"xyzzy" into the current branch.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:45 ` Linus Torvalds
@ 2006-11-15 22:52 ` Carl Worth
2006-11-15 23:02 ` Shawn Pearce
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
On Wed, 15 Nov 2006 13:45:58 -0800 (PST), Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Carl Worth wrote:
> >
> > Well, one of the problems is that with current git I can teach, (and I
> > have), that there's a conceptual:
> >
> > pull = fetch + merge
> >
> > But then shortly after I have to teach an interface notion:
> >
> > merge = pull .
>
> This is why I would suggest teaching the _concept_ of the "merge", and not
> the actual command.
>
> I don't think you should basically ever use the "git merge" command
> itself, not in teaching, and not in real life.
I think that's just and accident of git-merge having such a bad
syntax, (requiring a merge message, not using -m for that, requiring
two heads instead of defaulting to current, etc.). So the result is
accepting another bad syntax "pull ." for an operation that really is
merge.
> Once you've explained the _concept_ of merging, you then introduce the
> command to actually _execute_ the merge: it's "git pull".
I think we'll be doing better when there is a stronger correlation
between the concepts of the operations and the command names for
carrying them out.
Plus, when I'm teaching "fetch everything first, then manipulate it
locally", (which is what I teach, since that's the only way I use
git), then the "." looks really out of place when I teach the 'merge'
command. I end up saying, "Oh, that's there because you could do the
fetch and merge all in one step if you really wanted, but I never do
that.".
And that's because I _do_ teach fetch first, as you've suggested.
> changes from both branches. So it's a _conceptual_ issue, and that's why I
> said I think you should just totally gloss over the whole issue of "git
> merge" syntax.
That doesn't work. I know I went looking at the git-merge
documentation when I started to learn git. "It can't really be this
hard, can it?" was my reaction to it. And then only after attending a
tutorial did I learn that "pull ." is the way it's really done.
That's nothing more than a user-interface trap for new users, plain
and simple.
The real fix is to stop glossing over git-merge and just give it a
usable syntax.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 22:52 ` Carl Worth
@ 2006-11-15 23:02 ` Shawn Pearce
2006-11-15 23:33 ` Linus Torvalds
2006-11-15 23:07 ` Sean
[not found] ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
2 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 23:02 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
Carl Worth <cworth@cworth.org> wrote:
> Plus, when I'm teaching "fetch everything first, then manipulate it
> locally", (which is what I teach, since that's the only way I use
> git), then the "." looks really out of place when I teach the 'merge'
> command. I end up saying, "Oh, that's there because you could do the
> fetch and merge all in one step if you really wanted, but I never do
> that.".
>
> And that's because I _do_ teach fetch first, as you've suggested.
Ditto. In every way.
I've taught the same fetch first, then merge strategy. Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
they always fetch locally, look at the incoming changes, decide if
its worthwhile/ok, *then* merge with "git pull . branch".
The "." looks out of place for everyone...
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 23:02 ` Shawn Pearce
@ 2006-11-15 23:33 ` Linus Torvalds
2006-11-16 0:08 ` Nicolas Pitre
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 23:33 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, Nicolas Pitre, Michael K. Edwards, git
On Wed, 15 Nov 2006, Shawn Pearce wrote:
>
> I've taught the same fetch first, then merge strategy. Nobody I
> know in meat-space pulls from a remote URL and merges in one shot;
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Of course, in a situation like git itself, where most of the merges are
stuff that Junio has had pending in his own tree ('maint' branch etc),
things are different. But in a system where people actually use separate
trees, there really is an advantage to consider the fundamental operation
to be the "pull", not the "merge".
Again, the kernel really is more distributed than most projects, but this
is another thing people should recognize: git has been designed for "true
distributed development". Not the "fake" kind. Not the "I merge mainly my
own branches" kind of thing. Truly distributed.
And in a truly distributed situation, "pull" is strictly more powerful
than a separate "fetch" + separate "merge".
In other words, an SCM that does "pull" is _better_ than an SCM that does
"merge". You can implement "merge" as a special case of "pull" (which we
do), but you cannot conveniently do it the other way around without having
to tie them together some other way (ie you could have a "remember the
last place we fetched this branch from in order to tie the fetch and the
merge together" - but please realize that that is exactly what "pull"
_is_).
So I will generally do a "git pull" (possibly followed by a "git reset
--hard ORIG_HEAD" if I decided it wasn't good) over a "git fetch" + "git
merge". Exactly because the "pull" operation is actually more powerful.
Maybe people who aren't in my position don't always appreciate the _power_
of git. The reason "merge" is a second-class citizen is simply because IT
SHOULD BE.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 23:33 ` Linus Torvalds
@ 2006-11-16 0:08 ` Nicolas Pitre
2006-11-16 3:07 ` Linus Torvalds
2006-11-16 3:02 ` Michael K. Edwards
2006-11-16 16:37 ` Carl Worth
2 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-16 0:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Shawn Pearce wrote:
> >
> > I've taught the same fetch first, then merge strategy. Nobody I
> > know in meat-space pulls from a remote URL and merges in one shot;
>
> Actually, with different people involved it's _much_ better to do it in
> one shot.
>
> Why? Because doing a separate "fetch to local space" + "merge from local
> space" actually loses the information on what you are merging.
>
> It's a lot more useful to have a merge message like
>
> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> Merge branch 'for-linus'
That is an implementation detail that should be easily overcome once the
notion of tracking branch with URL attribute is implemented. Then it
will be really easy to notice whether the branch argument is a local
branch or a tracking branch with remote reference.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 0:08 ` Nicolas Pitre
@ 2006-11-16 3:07 ` Linus Torvalds
2006-11-16 3:43 ` Nicolas Pitre
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 3:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> That is an implementation detail that should be easily overcome once the
> notion of tracking branch with URL attribute is implemented.
Nope.
I simply don't _have_ those branches.
Why? Because the kernel is _distributed_. There is no central place
(certainly not my repository) that tracks all the possible branches that
might get merged.
In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
sense to have a "pull" that fetches and merges, over something that
fetches separately and then merges. Because in a truly distributed
environment, you simply DO NOT HAVE static branches that you can associate
with particular sources.
See?
And the thing is, I think the git design should be geared towards true
distribution. It should NOT be geared toward a fairly static set of
branches that all have a fairly static set of other repositories
associated with them. Can you see the difference?
I'm personally convinced that one of the reasons people tend to use git in
a centralized manner is just a mental disease that has its roots in how
they used _other_ SCM's. I don't want git design to be polluted by such a
centralized notion.
So to repeat: you can always make "pull" boil down to "pull from myself"
(aka just "merge"), but you can _not_ make "fetch + merge" boil down to
"pull" without meking up extra state to track separately. In other words,
"pull" really is the strictly more powerful operation.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:07 ` Linus Torvalds
@ 2006-11-16 3:43 ` Nicolas Pitre
0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-16 3:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Carl Worth, Michael K. Edwards, git
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > That is an implementation detail that should be easily overcome once the
> > notion of tracking branch with URL attribute is implemented.
>
> Nope.
>
> I simply don't _have_ those branches.
>
> Why? Because the kernel is _distributed_. There is no central place
> (certainly not my repository) that tracks all the possible branches that
> might get merged.
>
> In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
> sense to have a "pull" that fetches and merges, over something that
> fetches separately and then merges.
[...]
OK fine. git-pull is there to stay and let's make sure it remains the
same.
Let's see if, for example, git-merge can be made more useful in the mean
time for those evidently inferior people that would prefer an interface
that maps more closely to the actual operation that is being performed.
And although I do understand what "pull" does, I think I should qualify
myself as one of those inferior people nevertheless since /pull . blah"
really irritates me. OK I must be really dumb to let myself being
disturbed by such an insignificant detail... but apparently I'm not
alone.
But I promise to never change the "pull" behavior if I ever attempt to
fix the "merge" command for the inferior mortals as myself. All power
to those with superior minds shall never be removed.
;-)
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 23:33 ` Linus Torvalds
2006-11-16 0:08 ` Nicolas Pitre
@ 2006-11-16 3:02 ` Michael K. Edwards
2006-11-16 11:35 ` Andreas Ericsson
2006-11-16 16:37 ` Carl Worth
2 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-16 3:02 UTC (permalink / raw)
To: git
On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, with different people involved it's _much_ better to do it in
> one shot.
>
> Why? Because doing a separate "fetch to local space" + "merge from local
> space" actually loses the information on what you are merging.
>
> It's a lot more useful to have a merge message like
>
> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> Merge branch 'for-linus'
>
> which is what you get if you fetched it first.
Full ACK from a platform integrator's perspective. Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible. It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.
I don't have to manually log the _mechanical_origin_ of a given delta;
git does that for me, and mostly just DTRT when the same delta arrives
via several paths. When I use git pull from a remote branch (with or
without an entry in remotes/heads, which for this purpose is just
shorthand), I don't have to manually log what conflicts I have and
haven't resolved, either; I must have assimilated whatever I cared
about in the remote branch's history up to that point, because as long
as there are things in that remote branch that I haven't decided how
to handle, I stick to cherry-picking.
Obviously, fetch to local space is great (especially when you spend
some of your working hours behind a firewall that blocks outbound TCP
9418). Fetch from local space is also great, when the local space you
are fetching from reflects local work (such as a sync point and
reconciliation of several upstream sources, which then needs to be
ported forward or back to the chosen core version for each platform).
Fetch from a local space that is just a tracker for remote work is not
great, because it doesn't capture the editorial decision implied by a
remote pull: I looked at what the remote branch had to offer as of
this date, systematically decided which bits did and didn't belong in
the branch to which I was pulling, and pulled.
The record of that pull becomes a first-class object because it's
attached to an actual content delta in the target branch. So it
propagates into branches that pull from it. Pulling this delta into
another branch is different from cherry-picking a feature delta; it
implies acceptance of the reconciliation and editorial work associated
with the merge in the source branch.
Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion. But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:02 ` Michael K. Edwards
@ 2006-11-16 11:35 ` Andreas Ericsson
0 siblings, 0 replies; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-16 11:35 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
Michael K. Edwards wrote:
> On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> Actually, with different people involved it's _much_ better to do it in
>> one shot.
>>
>> Why? Because doing a separate "fetch to local space" + "merge from local
>> space" actually loses the information on what you are merging.
>>
>> It's a lot more useful to have a merge message like
>>
>> Merge branch 'for-linus' of
>> git://one.firstfloor.org/home/andi/git/linux-2.6
>>
>> than one like
>>
>> Merge branch 'for-linus'
>>
>> which is what you get if you fetched it first.
>
> Full ACK from a platform integrator's perspective. Local merge is
> great for trial runs but the history in a persistent branch should be
> as self-contained and self-explanatory as possible. It shouldn't
> depend on what I name local tracking branches, which are just a
> convenience so that I can still do trial runs when my connectivity is
> broken.
>
[...]
>
> Coming from me, this is all rather theoretical, as I haven't been
> using this particular tool for the purpose long enough to have an
> independent opinion. But for what it's worth, the workflow Linus
> describes isn't just for the guy at the top of the pyramid.
>
I think it's unfortunate that git was originally written by Linus, since
he so obviously is "the guy at the top of the pyramid" in many more
senses than just "Linus said this and that patch was OK to commit",
since git was designed to work like king Arthur's round table; "Linus is
in the same circle as me, so ofcourse we help each other out".
All suggestions I've been reading about tracking branches,
separate-remotes and whatnot have their merit. If any of it gets
implemented, I'd still like to be able to do one-shot pulls from remote
repos *without* creating specific tracking branches for it. It's
extremely useful to fetch other peoples topic-branches into my own
"master" (or topic-branch) when I trust their changes to be good. Please
consider that when you're hacking away on whatever changes to do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 23:33 ` Linus Torvalds
2006-11-16 0:08 ` Nicolas Pitre
2006-11-16 3:02 ` Michael K. Edwards
@ 2006-11-16 16:37 ` Carl Worth
2006-11-16 17:57 ` Michael K. Edwards
2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 16:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Nicolas Pitre, Michael K. Edwards, git
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Wed, 15 Nov 2006 15:33:43 -0800 (PST), Linus Torvalds wrote:
> It's a lot more useful to have a merge message like
>
> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
>
> than one like
>
> Merge branch 'for-linus'
There's more information in the first, sure. But I absolutely don't
accept that it's necessarily more useful, and definitely not that this
is a good argument for using pull with a remote branch instead of
fetch followed by merge with a local branch.
First, the pull may just fast-forward in which case there's no message
at all. And we've been through that topic enough recently that we all
know that no important information is lost by not doing any separate
recording in that case.
So you can't turn around and argue that the remote URL information is
suddenly important when it just so happens that it's not a fast
forward.
> And in a truly distributed situation, "pull" is strictly more powerful
> than a separate "fetch" + separate "merge".
I don't buy it. In my usage, I have several different remote
repositories I'm interested in tracking, each with any number of
branches. What I really want is an easy command that fetches all of
those branches, (even new ones that I've never heard about---but never
any of their "tracking branches" that wouldn't be of interest to
me). And I want to do that once, to get the online-access-required
part over with and get all the data into my local repository where I
can start working with it.
As for the URL from which I'm fetching all this stuff, it's really not
interesting to me at all. The URL for "Keith's stuff" keeps changing
anyway---I have no interest in recording that. But I do think it's
worth recording that the commits came from Keith's repository. I do
that right now with a keith/ prefix for his branches. It could also be
done by bringing in his .git/description during the fetch and storing
it somewhere. But I honestly don't see how storing something like that
during would make the system any less distributed in any sense.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:37 ` Carl Worth
@ 2006-11-16 17:57 ` Michael K. Edwards
2006-11-16 18:23 ` Carl Worth
0 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-16 17:57 UTC (permalink / raw)
To: Carl Worth; +Cc: git
On 11/16/06, Carl Worth <cworth@cworth.org> wrote:
> First, the pull may just fast-forward in which case there's no message
> at all. And we've been through that topic enough recently that we all
> know that no important information is lost by not doing any separate
> recording in that case.
>
> So you can't turn around and argue that the remote URL information is
> suddenly important when it just so happens that it's not a fast
> forward.
When it's a fast forward, the puller hasn't had to make any judgment
calls, so there's no editorial history to record. When it's not, but
the puller chooses to retain the result on a persistent branch, that
_is_ an editorial decision (even if the result of the auto-merge is
clean); I like having that in the history.
> > And in a truly distributed situation, "pull" is strictly more powerful
> > than a separate "fetch" + separate "merge".
>
> I don't buy it. In my usage, I have several different remote
> repositories I'm interested in tracking, each with any number of
> branches. What I really want is an easy command that fetches all of
> those branches, (even new ones that I've never heard about---but never
> any of their "tracking branches" that wouldn't be of interest to
> me). And I want to do that once, to get the online-access-required
> part over with and get all the data into my local repository where I
> can start working with it.
What do you want all of those branches for? They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.
I do agree that a robust form of "for b in .git/remotes/*; do git
fetch `basename $b`; done" would be a nice bit of porcelain. The
entries in .git/remotes would probably need to grow a "Fetch-options:"
field so that you could choose whether or not to follow tags, etc.
Patch to follow.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:57 ` Michael K. Edwards
@ 2006-11-16 18:23 ` Carl Worth
2006-11-17 8:41 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 18:23 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
> What do you want all of those branches for? They haven't been
> published to you (that's a human interaction that doesn't go through
> git), so for all you know they're just upstream experiments, and doing
> things with them is probably shooting yourself in the foot.
The same "what do you want them all for" question could be asked of
git-clone which also fetches all available branches. I really just
want to be able to easily watch what's going on in multiple
repositories.
I want to be able to just say "git update" (or whatever) and then be
able to list and browse and explore the stuff locally.
Yes, there's still outside communication that's necessary, but with
the ability to easily track all the remote branches that communication
can be even less formal if I can easily browse and explore things
locally. For example, I might not even know the name of the branch:
Me: Have you pushed a branch for your new work on the frob-widget?
Friend: Yes
And then I can "get fetch" and see "cool-new-frob" come in without
having to be told that name. Or I could have even just fetched
without the specific communication if I was already expecting it for
some reason.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 18:23 ` Carl Worth
@ 2006-11-17 8:41 ` Junio C Hamano
2006-11-17 9:18 ` Carl Worth
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 8:41 UTC (permalink / raw)
To: Carl Worth; +Cc: Michael K. Edwards, git
Carl Worth <cworth@cworth.org> writes:
> On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
>> What do you want all of those branches for? They haven't been
>> published to you (that's a human interaction that doesn't go through
>> git), so for all you know they're just upstream experiments, and doing
>> things with them is probably shooting yourself in the foot.
>
> The same "what do you want them all for" question could be asked of
> git-clone which also fetches all available branches. I really just
> want to be able to easily watch what's going on in multiple
> repositories.
>
> I want to be able to just say "git update" (or whatever) and then be
> able to list and browse and explore the stuff locally.
>...
I have no objection to this if it is done in a controlled way
that does not make life more difficult for people who work with
multiple remote repositories.
And I think "git fetch" is the tool for what you want if
enhanced properly; see Linus's message that explaind that we
already have that support in "manually configurable" form but
initializing and maintaining the configuration is currently all
manual and can be improved.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 8:41 ` Junio C Hamano
@ 2006-11-17 9:18 ` Carl Worth
2006-11-17 10:11 ` Johannes Schindelin
2006-11-17 11:29 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael K. Edwards, git
[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]
On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote:
> I have no objection to this if it is done in a controlled way
> that does not make life more difficult for people who work with
> multiple remote repositories.
That's fine with me. Maybe I didn't explain this well before, but my
desire is exactly for this to work with multiple repositories.
Specifically, what we have in cairo is a "central" shared tree that
many people push to. But we only have two branches there, (one for
bug-fixes only for our stable releases, and one for ongoing
development of new features, and that only of stuff that's well
cooked).
So that tree looks and acts an awful lot like our cvs tree back in the
past. It's often very linear and often fairly boring to look at in gitk.
Meanwhile, all the really interesting stuff happens in personal
repositories where people have their own branches for stuff that is
still getting cooked. This is what's a lot more fun to watch, and
there's a lot more distributed back-and-forth that goes on here as
people collaborate on things. And it's all this kind of collaboration
that cvs never helped with at all, but git has been great.
So, what I want is both "git update" for the central tree. I said we
only have two branches, but that's really only two that are
active---the "stable" branch is actually a new branch after every
major release. It was 1.0 for a while, is 1.2 now, and will be 1.4
later. So I want "git update" to automatically pick those new branches
up as they get created.
Meanwhile, I also want to use "git update" to track everything that
people are working on in the more wild personal trees. So, yes, I do
want "git update" to be able to track lots of remote repositories in a
sane way.
What I have been doing up to this point is a little script I wrote
that does git-ls-remote on the repository I want to track and writes a
.git/remotes file to bring in all their branches. So if I want to see
what behdad is up to, I first refresh his .git/remotes file with my:
cairo-git-setup-remotes behdad
then:
git fetch behdad
And I end up with a bunch of branch names with "behdad-" prefixes that
I can explore or blow away if I'm no longer interested, (could have
used a "behdad/" prefix as well).
The first problem we ran into when doing that months ago was that I
don't want any tracking branches to come across this way. Or else I
end up with behdad-origin, he then gets cworth-behdad-origin, ad
nauseum. So we filtered "origin" out, but it will be nice to revisit
this if there's a sane distinction in git now to separate tracking
branches from heads.
> And I think "git fetch" is the tool for what you want if
> enhanced properly; see Linus's message that explaind that we
> already have that support in "manually configurable" form but
> initializing and maintaining the configuration is currently all
> manual and can be improved.
Yes, git-fetch is lovely, and it's the need for manual configuration
that's a problem, (and the mixing up of heads and remote tracking
branches that has been in git historically).
So, yes, I'll definitely look into improving this. I think the details
will involve:
1. Making clone do the --use-separate-remotes behavior by default
2. Taking advantage of that consistently for all branches instead of a
special master:origin mapping in clone
3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
there a desire for some other branch-specific section in the config
file?)
4. Making git-fetch handle the disappearance of a remote branch
gracefully
5. Adding something like git-fetch --all to allow it to pick up all new
branches
6. Adding a "git update" that does a fetch for all appropriately
marked remotes.
On this last point, maybe we do something like:
update=no|yes|all
in .git/remotes. Then git-clone would set this up with update=all for
origin so git-update would do a "fetch --all" on the origin
repository. Then step 3 above would have to provide for setting this
update option as appropriate.
Anyway, something along those lines perhaps. Any feedback?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 9:18 ` Carl Worth
@ 2006-11-17 10:11 ` Johannes Schindelin
2006-11-17 11:41 ` Junio C Hamano
2006-11-17 16:58 ` Shawn Pearce
2006-11-17 11:29 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17 10:11 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Michael K. Edwards, git
Hi,
On Fri, 17 Nov 2006, Carl Worth wrote:
> 1. Making clone do the --use-separate-remotes behavior by default
Fully agree.
> 2. Taking advantage of that consistently for all branches instead of a
> special master:origin mapping in clone
Fully agree, too.
> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
> there a desire for some other branch-specific section in the config
> file?)
I introduced the remote.<nick>.{url,fetch,push} entries into the config
with the goal to enhance -fetch to remember the current command line with
a setting. I was the only one to find that useful.
BTW I still would argue that it is better to write the remote information
into the config, because you have a saner way to manipulate that from
scripts than .git/remotes/<nick>.
> 4. Making git-fetch handle the disappearance of a remote branch
> gracefully
I think a message like "This remote branch no longer exists. Maybe you
want to use 'git branch -d <branch>' to remove it locally?" should
suffice.
> 5. Adding something like git-fetch --all to allow it to pick up all new
> branches
IIRC this idea was rejected, but I would find it useful. Especially with
what Han-Wen said: you can store the branches you fetch with "git fetch
--all <nick>" under .git/refs/remotes/<nick>/<branchname>.
> 6. Adding a "git update" that does a fetch for all appropriately
> marked remotes.
>
> On this last point, maybe we do something like:
>
> update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.
First thought was: it is only useful if you want to track multiple
repositories. But next thought: if you mark the correct remotes in every
of your local repositories, you don't have to remember which nick your
upstream has. Yeah, I like it. But maybe do it as "git fetch --update" to
avoid more cluttering of the bindir?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 10:11 ` Johannes Schindelin
@ 2006-11-17 11:41 ` Junio C Hamano
2006-11-17 16:58 ` Shawn Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Michael K. Edwards, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 5. Adding something like git-fetch --all to allow it to pick up all new
>> branches
>
> IIRC this idea was rejected, but I would find it useful. Especially with
> what Han-Wen said: you can store the branches you fetch with "git fetch
> --all <nick>" under .git/refs/remotes/<nick>/<branchname>.
With separate-remote layout, this can be done without risk of
tracking refname clashing with local refname, which was the
primary reason for an earlier reluctance.
While separate-remote layout also solves Carl's "do not want to
track tracking branches remote has" problem, local branch
namespace can have both for-others (not necessarily "public" but
could be "for colleagues") and throwaway branches, so --all is
probably not the right thing to do in most cases. But I am Ok
with the approach of seeing how well it works out in practice by
doing the simplest "--all" and giving options to restrict it
later.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 10:11 ` Johannes Schindelin
2006-11-17 11:41 ` Junio C Hamano
@ 2006-11-17 16:58 ` Shawn Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Junio C Hamano, Michael K. Edwards, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I introduced the remote.<nick>.{url,fetch,push} entries into the config
> with the goal to enhance -fetch to remember the current command line with
> a setting. I was the only one to find that useful.
>
> BTW I still would argue that it is better to write the remote information
> into the config, because you have a saner way to manipulate that from
> scripts than .git/remotes/<nick>.
I'm *fully* in favor of the remote.<nick>.{url,fetch,push} entries
in the config file. I've pretty much switched every repository to
that format at this point.
In writing git-gui I'm finding it much, much easier to manage
things through repo-config than to do any mucking around in the
.git/remotes directory. Yes, the remote files have simple format,
but I can get everything in one "git repo-config --list" pull it
all into a Tcl array and work with it; using .git/remotes means I
have to open the file and read each line too. :-(
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 9:18 ` Carl Worth
2006-11-17 10:11 ` Johannes Schindelin
@ 2006-11-17 11:29 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 11:29 UTC (permalink / raw)
To: Carl Worth; +Cc: Michael K. Edwards, git
Carl Worth <cworth@cworth.org> writes:
> What I have been doing up to this point is a little script I wrote
> that does git-ls-remote on the repository I want to track and writes a
> .git/remotes file to bring in all their branches. So if I want to see
> what behdad is up to, I first refresh his .git/remotes file with my:
>
> cairo-git-setup-remotes behdad
> then:
> git fetch behdad
>
> And I end up with a bunch of branch names with "behdad-" prefixes that
> I can explore or blow away if I'm no longer interested, (could have
> used a "behdad/" prefix as well).
I would suggest refs/remotes/behdad.
> So, yes, I'll definitely look into improving this. I think the details
> will involve:
>
> 1. Making clone do the --use-separate-remotes behavior by default
>
> 2. Taking advantage of that consistently for all branches instead of a
> special master:origin mapping in clone
This already should be the case if you use separate-remote. I
haven't run "clone --separate-remote" myself for a long time,
but the design was certainly to make it behave that way.
Specifically, map everything in refs/heads/ at remote to
refs/remotes/$origin/ with corresponding names, one-to-one.
I do not see much reason to change the mapping of master:origin
which is done for the traditional layout. The traditional
layout is not suitable for your workflow anyway, and that is why
you prefer separate-remote layout for your project, and I fully
agree it would suit you better.
> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
> there a desire for some other branch-specific section in the config
> file?)
>
> 4. Making git-fetch handle the disappearance of a remote branch
> gracefully
>
> 5. Adding something like git-fetch --all to allow it to pick up all new
> branches
These three are easily done for separate-remote layout but at
that point you would not want --all but more powerful --mirror
(or --update if you want to use that word), which goes the whole
nine yards of noticing disappearance of remote branch, making
matching deletion of local tracking branch, updating
.git/remotes, etc. I've muttered something similar in a nearby
thread; see below.
> 6. Adding a "git update" that does a fetch for all appropriately
> marked remotes.
>
> On this last point, maybe we do something like:
>
> update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.
I would prefer this to be kept in contrib/; it feels like it is
filling rather very narrow need.
> Anyway, something along those lines perhaps. Any feedback?
I muttered something less elaborate in the nearby thread.
Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
Message-ID: <7v64dev88t.fsf@assigned-by-dhcp.cox.net>
The part that deals with manual configuration (the last point in
the first message, and the second in message its entirety) is
something your workflow would not need nor want to worry about,
but I think it is necessary for different ref namespace layouts
and different workflows. I think the automatable part (the
first two points in the "sensible thing to do" list in the first
message) is very relevant to what you talked about in your
message.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 22:52 ` Carl Worth
2006-11-15 23:02 ` Shawn Pearce
@ 2006-11-15 23:07 ` Sean
[not found] ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
2 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 23:07 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
On Wed, 15 Nov 2006 14:52:32 -0800
Carl Worth <cworth@cworth.org> wrote:
> The real fix is to stop glossing over git-merge and just give it a
> usable syntax.
Agreed 100% There's just no good reason to hide the user level
merge command inside of pull.
^ permalink raw reply [flat|nested] 601+ messages in thread
[parent not found: <20061115180722.83ff8990.seanlkml@sympatico.ca>]
* Re: Cleaning up git user-interface warts
[not found] ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
@ 2006-11-15 23:15 ` Shawn Pearce
2006-11-16 7:51 ` Richard CURNOW
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 23:15 UTC (permalink / raw)
To: Sean; +Cc: Carl Worth, Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
Sean <seanlkml@sympatico.ca> wrote:
> On Wed, 15 Nov 2006 14:52:32 -0800
> Carl Worth <cworth@cworth.org> wrote:
>
> > The real fix is to stop glossing over git-merge and just give it a
> > usable syntax.
>
> Agreed 100% There's just no good reason to hide the user level
> merge command inside of pull.
So what about making git-merge take a -m "msg" argument to supply
the commit message, in which case it does the current behavior
(and thus git-pull needs to change to supply -m); and then make
git-merge without any -m parameter invoke "git pull . $@" ?
A minor tweak to both apps, a minor breakage to git-merge, but one
that I think anyone who invokes it by hand today would find sane
(using -m like we do elsewhere) and since the vintage of both
git-pull and git-merge should always match shouldn't break anyone
who uses git-pull today.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 23:15 ` Shawn Pearce
@ 2006-11-16 7:51 ` Richard CURNOW
2006-11-16 23:01 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Richard CURNOW @ 2006-11-16 7:51 UTC (permalink / raw)
To: git
Cc: Shawn Pearce, Sean, Carl Worth, Linus Torvalds, Nicolas Pitre,
Michael K. Edwards
* Shawn Pearce <spearce@spearce.org> [2006-11-15]:
>
> So what about making git-merge take a -m "msg" argument to supply
> the commit message, in which case it does the current behavior
> (and thus git-pull needs to change to supply -m); and then make
> git-merge without any -m parameter invoke "git pull . $@" ?
Sounds good to me.
When I'm merging in my own projects, I currently always use merge
(possibly preceded by fetch) rather than pull. Why? Because I don't
want my history full of commit messages like
Merge branch "trial_hack" from "../scratch_dir_with_silly_name"
In contrast to Linus's case of wanting to record where the remote merge
came from, I expressly don't want to record that - I want the merge
commit to describe conceptually what was being merged with what.
OK, I could use probably use pull with --no-commit, but I've already
trained my fingers to type out the merge syntax. They'd be happier with
'git merge -m "Merge feature foo with fixes for bar" bar" though.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 7:51 ` Richard CURNOW
@ 2006-11-16 23:01 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:01 UTC (permalink / raw)
To: Richard CURNOW; +Cc: git
Hi,
On Thu, 16 Nov 2006, Richard CURNOW wrote:
> In contrast to Linus's case of wanting to record where the remote merge
> came from, I expressly don't want to record that - I want the merge
> commit to describe conceptually what was being merged with what.
>
> OK, I could use probably use pull with --no-commit, but I've already
> trained my fingers to type out the merge syntax. They'd be happier with
> 'git merge -m "Merge feature foo with fixes for bar" bar" though.
For the moment, if you forget --no-commit, you can always do a "git-commit
--amend" -- even with merges.
Hth,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:08 ` Carl Worth
2006-11-15 21:31 ` Junio C Hamano
2006-11-15 21:45 ` Linus Torvalds
@ 2006-11-21 13:25 ` Jerome Lovy
2 siblings, 0 replies; 601+ messages in thread
From: Jerome Lovy @ 2006-11-21 13:25 UTC (permalink / raw)
To: git
On Wed, 15 Nov 2006, Carl Worth wrote:
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
>
> pull = fetch + merge
>
> But then shortly after I have to teach an interface notion:
>
> merge = pull .
>
> So there's this goofy circular notion that people end up with
> mentally. If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.
On a conceptual level, can we not perhaps explain that if
pull = fetch + merge
then
merge = pull - fetch
and that the latter (pull - fetch) happens to be expressed with the
interface as 'git pull .' ?
My 2 cents.
Jérôme
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:40 ` Linus Torvalds
2006-11-15 21:08 ` Carl Worth
@ 2006-11-16 4:26 ` Theodore Tso
2006-11-16 11:50 ` Andreas Ericsson
1 sibling, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Michael K. Edwards, git
On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
> And yes, this is why you should NOT try to use the same naming as "hg",
> for example. Last I saw, hg still didn't even have local branches, To
> mercurial, repository == branch, and that's it. It was what I came from
> too, and I used to argue for using git that way too. I've since seen the
> error of my ways, and git is simply BETTER.
Actually, that's not true. Mercurial has local branches, just as git
does. Some people choose not to *use* this particular feature, and
use the BK style repository == branch, but that's mainly because it's
conceptually easy for them, and a number of BK refugees are very
happily using Hg.
It's probably because of the BK refugee population that after you do
an hg pull, it will warn you that you need to do an "hg update" in
order to merge the working directory up to the latest version that was
just pulled --- and this change was made precisely because Hg supports
local branches, and merging with the current branch isn't always the
right thing, unlike with BK.
> And the concept of local branches is exactly _why_ you have to have
> separate "fetch" and "pull", but why you do _not_ need a separate "merge"
> (because "pull ." does it for you).
It's just that the semantics are different, and many developers have
to use multiple DSCM's, depending on what project they happen to be
developing on. So the reality is that there are people who have to
use bzr, git, and hg, all at the same time. And while eventually
newbies will figure out and remember that "git pull ." == "merge", the
naming is simply confusing, that's all. (What does "pull" have to do
with "merge"? It's not at all obvious.)
For somoene who uses git full-time, and to the exclusion of all other
systems, I'm sure it's not a problem at all.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 4:26 ` Theodore Tso
@ 2006-11-16 11:50 ` Andreas Ericsson
2006-11-16 16:30 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-16 11:50 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Nicolas Pitre, Michael K. Edwards, git
Theodore Tso wrote:
> On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
>> And yes, this is why you should NOT try to use the same naming as "hg",
>> for example. Last I saw, hg still didn't even have local branches, To
>> mercurial, repository == branch, and that's it. It was what I came from
>> too, and I used to argue for using git that way too. I've since seen the
>> error of my ways, and git is simply BETTER.
>
> Actually, that's not true. Mercurial has local branches, just as git
> does. Some people choose not to *use* this particular feature, and
> use the BK style repository == branch, but that's mainly because it's
> conceptually easy for them, and a number of BK refugees are very
> happily using Hg.
>
> It's probably because of the BK refugee population that after you do
> an hg pull, it will warn you that you need to do an "hg update" in
> order to merge the working directory up to the latest version that was
> just pulled --- and this change was made precisely because Hg supports
> local branches, and merging with the current branch isn't always the
> right thing, unlike with BK.
>
>> And the concept of local branches is exactly _why_ you have to have
>> separate "fetch" and "pull", but why you do _not_ need a separate "merge"
>> (because "pull ." does it for you).
>
> It's just that the semantics are different, and many developers have
> to use multiple DSCM's, depending on what project they happen to be
> developing on. So the reality is that there are people who have to
> use bzr, git, and hg, all at the same time. And while eventually
> newbies will figure out and remember that "git pull ." == "merge", the
> naming is simply confusing, that's all. (What does "pull" have to do
> with "merge"? It's not at all obvious.)
>
> For somoene who uses git full-time, and to the exclusion of all other
> systems, I'm sure it's not a problem at all.
It seems we should, cheaply, be able to avoid a large part of the
confusion by
* Mentioning git-fetch before git-pull in all documentation newborn
gitizens are likely to come across. Most git-users aren't Linus, and for
every successful project the maintainers are outnumbered 100 to 1 by the
contributors. Those projects successful *because* maintainers are
heavily outnumbered so we should make it easier for contributors by
teaching them the right things from the start and possibly have a
separate man-page for maintainer (git-{maintainer,developer} man-pages,
anyone?).
* Creating "git update" which might possibly be an internal alias to
"git pull", except that it should read .git/remotes/* by default unless
a specific remotes-file is specified.
* Renaming git-merge to git-merge-driver
* Implementing a git-merge that actually does what its name implies,
possibly by making it an internal alias to pull, but with these differences:
- It always merges into your current branch.
- It understands "git merge branch" as well as "git merge . branch".
This is just the very low-hanging fruit. If we take these steps and let
things cool down a bit, it would probably be proper to take a fresh look
at this in a couple of months.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:50 ` Andreas Ericsson
@ 2006-11-16 16:30 ` Linus Torvalds
2006-11-16 17:01 ` Carl Worth
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 16:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Theodore Tso, Nicolas Pitre, Michael K. Edwards, git
On Thu, 16 Nov 2006, Andreas Ericsson wrote:
>
> * Mentioning git-fetch before git-pull in all documentation newborn gitizens
> are likely to come across.
However, I also think it might make sense to talk about the _simple_ form
of "git pull" first.
The form I use is actually a lot simpler (conceptually) than the "short"
form.
When you do
git pull <reponame> <branchname>
there are very few things that can confuse you (although trying to do it
without a current branch at all is apparently one such thing ;).
There are no local branches to worry about, and there aren't any issues
about what the default repository or branchname on the remote side would
be either.
So in many ways, if you use this format, you simply never have to worry.
You may have to _type_ a bit more, so it's not the short or concise
format, but it sure is the _simple_ format. There simply isn't anything to
be confused about.
And yes, I actually tend to use this even for project that I don't develop
on, partly because the defaults for the short and concise formats are bad.
For example, I follow the "modesetting" branch on the xorg intel graphics
driver tree, and because I'm always on that branch, what I do is
git pull origin modesetting
which works correctly (while "git pull" would _not_ have done the right
thing: it would have picked the right repository, but it would have picked
the "master" branch of that repository, not the "modesetting" branch).
And notice how I don't do _any_ development there, I just follow that
branch. The "merge" will obviously always be a fast-forward, but that's
exactly what I want.
> Most git-users aren't Linus, and for every successful project the
> maintainers are outnumbered 100 to 1 by the contributors.
Well, as mentioned, I think even for non-developers, doing pulls with
explicit branchnames is actually perfectly sane.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:30 ` Linus Torvalds
@ 2006-11-16 17:01 ` Carl Worth
2006-11-16 17:30 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-16 17:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards, git
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> The form I use is actually a lot simpler (conceptually) than the "short"
> form.
>
> When you do
>
> git pull <reponame> <branchname>
Yes, that's what the user almost always wants. The UI problem here is
that the conceptually simpler form is syntactically longer, (which
means users aren't likely to find it).
So if we can just get <reponame> and <branchname> to default
correctly, (based on the current branch name, and clone/fetch/pull
history), then the conceptually simple form ends up syntactically
simple as "git pull".
And I definitely don't have any problem with that. I'd love to be able
to teach that kind of simple thing to new users.
> driver tree, and because I'm always on that branch, what I do is
>
> git pull origin modesetting
...
> Well, as mentioned, I think even for non-developers, doing pulls with
> explicit branchnames is actually perfectly sane.
The behavior is sane, but having to always type the branch name
specifically because it never changes... that's a user-interface bug.
This is a good example of the kind of thing I wanted to hit when
starting this thread. I don't think there are any big conceptual
changes needed in git to make it easier for new users. But there are
little things that are problems that really should be fixed. Wouldn't
it be great to have the following exchange:
User: How do I track on-going development in a branch?
Master: Use "git pull"
Rather than:
User: How do I track on-going development in a branch?
Master Use "git pull origin <name-of-branch-you-are-already-on>"
?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:01 ` Carl Worth
@ 2006-11-16 17:30 ` Linus Torvalds
2006-11-16 17:44 ` Sean
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:30 UTC (permalink / raw)
To: Carl Worth
Cc: Andreas Ericsson, Theodore Tso, Nicolas Pitre, Michael K. Edwards, git
On Thu, 16 Nov 2006, Carl Worth wrote:
>
> On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
> > The form I use is actually a lot simpler (conceptually) than the "short"
> > form.
> >
> > When you do
> >
> > git pull <reponame> <branchname>
>
> Yes, that's what the user almost always wants. The UI problem here is
> that the conceptually simpler form is syntactically longer, (which
> means users aren't likely to find it).
Yeah.
And this is something I absolutely agree with. Our default branches for
"pull" are horrible. You can "fix" it, but you can only fix it by adding
_explicit_ branches to your .git/config file by hand, so I don't think
that's actually a real fix at all. We should just fix the default (where
even a "I don't know what branch you want" _error_ would be preferable
over the current situation).
Along with the "git checkout <tag>" thing, I think these two things are
definitely worth just fixing.
> The behavior is sane, but having to always type the branch name
> specifically because it never changes... that's a user-interface bug.
Yeah. Each branch should
(a) have a "default source" initialized on the initial "clone"
(b) have a way to set the source afterwards
(c) error out if you do just a "git pull" or "git pull remotename" if
there is no default branch for the current local branch for that
remote.
We actually have (b) in a weak form right now ("weak" because it requires
you to manually edit the config file: we've got the mechanism, but not a
nice UI for it), but (a) and (c) are just broken.
And yeah, we should allow pulling into a branch that hasn't been
initialized.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:30 ` Linus Torvalds
@ 2006-11-16 17:44 ` Sean
0 siblings, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-16 17:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carl Worth, Andreas Ericsson, Theodore Tso, Nicolas Pitre,
Michael K. Edwards, git
On Thu, 16 Nov 2006 09:30:47 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> Yeah. Each branch should
>
> (a) have a "default source" initialized on the initial "clone"
>
> (b) have a way to set the source afterwards
>
> (c) error out if you do just a "git pull" or "git pull remotename" if
> there is no default branch for the current local branch for that
> remote.
This would be _great_. You just shouldn't have to hack at the
.git/config file to get reasonable default sources after a clone.
Or even for that matter after fetching a new branch into an
existing repo.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:18 ` Linus Torvalds
2006-11-15 19:39 ` Michael K. Edwards
@ 2006-11-16 1:40 ` Anand Kumria
1 sibling, 0 replies; 601+ messages in thread
From: Anand Kumria @ 2006-11-16 1:40 UTC (permalink / raw)
To: git
On Wed, 15 Nov 2006 11:18:36 -0800, Linus Torvalds wrote:
> On Wed, 15 Nov 2006, Andy Parkins wrote:
>>
>> On the one hand you're arguing that git syntax is easy to learn, and on the
>> other that no one will be able to learn a new syntax just as easily.
>
> I'm saying that people who are new to git will _have_ to learn new
> concepts ANYWAY.
>
> I don't think the naming is the hard part.
It isn't - the unexpectedness of what happens is.
I've started by teaching how to do stuff locally, then "pushing" it out to
others (me). All the while being able to point out how this is either all
local, or sends stuff (without any local modifications) to others.
Come up to 'pull' and ere you have to point out that not only will you get
the remote changes but they are also merged into your repository. On the
wrong branch?
Too bad.
The problem with git-pull behaving illogically drove me to look at cogito
(an aside, perhaps cg-throw should be the corrollary to cg-fetch?)
instead. Alas it has problems with a cogito branch not being something you
can mentally map back to a git branch.
> But I bet people don't teach it that way. They _start_ by teaching "pull".
> Right?
Nope.
Anand
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:58 ` Andy Parkins
2006-11-15 19:18 ` Linus Torvalds
@ 2006-11-15 19:32 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 19:32 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
>> But trying to rename "pull" (or the "git" name itself) is just going to
>> cause more confusion than you fix.
>
> I don't think so. Mainly because the proposed new git pull would be a subset
> of the existing git pull. It's not changing function, it's just reducing in
> function.
We usually use the word "regression" to refer to that kind of
change.
I think it makes a lot of sense having command x that does
essentially the same thing as the current fetch but with more
usability enhancements and more convention as built-in defaults,
and another command y that does what the current 'pull .' does
but with more usability enhancements and more convention as
built-in defaults. I agree that kind of UI improvements would
make it easier to explain to new people. Calling x "pull",
however, breaks the existing users and documents, and causes
confusion. I really do not think you can argue with that.
That's why we are talking about using an uncontaminated word
"get". I think it is a good effort.
>> aren't that complicated. There's no reason to rename them. We do have
>> other problems:
>
> That there are other problems doesn't negate these problems.
And I think Linus is right in pointing out that there are other
problems that are equally or even more pressing than _renaming_
to break things for existing users.
I personally do not think the current fetch/pull confusing, and
I do see real downside in _renaming_ them, but I am open to the
current get/put discussion because I think the new commands'
semantics may be designed to match newcomers' expectation better
(it's to match tools to newcomers instead of teaching them the
new language of the land) and I do not think that approach would
break existing users and documents.
For some things "matching tools to newcomers" would not really
work, though. For example, I do not think you can get away with
hiding index forever if you want your users to do real work in a
workflow that involves merging and cherry picking.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
` (2 preceding siblings ...)
2006-11-15 18:58 ` Andy Parkins
@ 2006-11-16 1:14 ` Theodore Tso
2006-11-16 4:21 ` Junio C Hamano
2006-11-16 1:20 ` Han-Wen Nienhuys
2006-11-16 4:30 ` Petr Baudis
5 siblings, 1 reply; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 1:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
On Wed, Nov 15, 2006 at 10:03:18AM -0800, Linus Torvalds wrote:
> So the reason for using "git pull" is
>
> - bk did it that way, and like it or not, bk was the first usable
> distributed system. hg is totally uninteresting.
Yes, "bk pull" had an implied merge. But, the reason why bk pull was
never really a problem with Bitkeeper is because it didn't really have
support for multiple branches active within the same repository ---
what Larry called "lines of development". Or rather, Larry started
down the path of implementing lines of development, and then never
fully supported it, mainly because making it easy for people to use
was the tricky part.
So with Bitkeeper, with "bk pull" there was never any question about
which branch ("line of development") you would be merging into after
doing a "bk pull", since there was only one LOD, and given that BK had
the rule that a within a LOD only one tip was allowed, a "bk pull"
_had_ to do do a merge operation.
The moment you start supporting multiple unmerged tips in a repository
i.e., branches, it raises the question, "which branch should the pull
operation merge onto"? And git's answer, "the current branch", is
often not the right one. *That's* why always doing a merge isn't
always the right answer, and so in the git world, people are told, use
"git fetch" instead, and in the hg world, "hg pull" doesn't do the
merge. IMO, it's a fundamental result of the fact that both git and
hg have chosen to support mulitple LOD's, whereas BK punted on the
concept.
If you are operating on your local development branch, the reality is
that merging is probably not the right answer in the general case,
which is why the hg world have omitted doing the merge. And by
telling people, use "git fetch" instead, that's also an implicit
admission that merging onto the current branch is often not the Right
Thing.
The problem is that "pull" is a very evocative word, especially given
the existence "push", and so in the git world we are reduced to
telling people, "you really don't want to use pull, trust me".
Is this a major issue? Not really; I can think of a number of other
issues that make git hard to learn, and why hg has a more gentle
learning curve, and the "don't use pull" is probably a relatively
minor annoyance in the grand scheme of things.
If people are looking for a simple way out, maybe it would be enough
to have an option where if "git pull" is called from an interactive
terminal, and the "novice user" option is enabled, "git pull" returns
a warning message, "You probably want to use 'git fetch' instead; are
you sure?" If people are saying that we shouldn't be teaching "git
pull" until fairly late in the game, maybe we should have a way of
discouraging novices from using, simply because they they are used to
seeing "pull" from other distributed SCM's.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 1:14 ` Theodore Tso
@ 2006-11-16 4:21 ` Junio C Hamano
2006-11-16 11:34 ` Alexandre Julliard
2006-11-16 16:07 ` Theodore Tso
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 4:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, Nicolas Pitre, Linus Torvalds
Theodore Tso <tytso@mit.edu> writes:
> So with Bitkeeper, with "bk pull" there was never any question about
> which branch ("line of development") you would be merging into after
> doing a "bk pull", since there was only one LOD, and given that BK had
> the rule that a within a LOD only one tip was allowed, a "bk pull"
> _had_ to do do a merge operation.
I've never used Bk and I really appreciate your comments here.
> If you are operating on your local development branch, the reality is
> that merging is probably not the right answer in the general case,
I agree, but I wonder why you are pulling/fetching (with or
without merge) if you are operating on your local development
branch (implying that you are in the middle of something else).
> ... And by
> telling people, use "git fetch" instead, that's also an implicit
> admission that merging onto the current branch is often not the Right
> Thing.
>
> The problem is that "pull" is a very evocative word, especially given
> the existence "push", and so in the git world we are reduced to
> telling people, "you really don't want to use pull, trust me".
I would rather say "use 'git branch' to make sure if you are
ready to merge". Who teaches not to use "git pull"?
> If people are looking for a simple way out, maybe it would be enough
> to have an option where if "git pull" is called from an interactive
> terminal, and the "novice user" option is enabled, "git pull" returns
> a warning message,
I have to disagree with this. In the simplest CVS-like central
repository with single branch setup in which many "novice users"
start out with, there is almost no need for "git fetch" nor
tracking branch. You pull, resolve conflicts, attempt to push
back, perhaps gets "oh, no fast forward somebody pushed first",
pull again, then push back. So I am not sure where "you really
do not want to use pull. trust me" comes from.
It is a different story for people who _know_ git enough to know
what is going on. They may be using multiple branches and
interacting with multiple remote branches, and there are times
you would want fetch and there are other times you would want
pull. But for them, I do think the suggestion would never end
with "trust me" -- they would understand what the differences
are.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 4:21 ` Junio C Hamano
@ 2006-11-16 11:34 ` Alexandre Julliard
2006-11-16 14:01 ` Petr Baudis
2006-11-17 13:32 ` Jakub Narebski
2006-11-16 16:07 ` Theodore Tso
1 sibling, 2 replies; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-16 11:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git, Nicolas Pitre, Linus Torvalds
Junio C Hamano <junkio@cox.net> writes:
> I would rather say "use 'git branch' to make sure if you are
> ready to merge". Who teaches not to use "git pull"?
We do that for Wine. The problem is that we recommend using git-rebase
to make it easier for occasional developers to keep a clean history,
and rebase and pull interfere badly.
The result is that we recommend always using fetch+rebase to keep up
to date, but this is confusing many people too, because git-fetch
appears to do a lot of work yet leaves the working tree completely
unchanged, and git-rebase doesn't do anything (since in most cases
they don't have commits to rebase) but has an apparently magical
side-effect of updating the working tree.
Ideally it should be possible to have git-rebase do the right thing
even if the branch has been merged into; then we could tell people to
always use git-pull, and when they get confused by seeing merges in
their history have them do a git-rebase to clean things up.
--
Alexandre Julliard
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:34 ` Alexandre Julliard
@ 2006-11-16 14:01 ` Petr Baudis
2006-11-16 15:48 ` Alexandre Julliard
2006-11-17 13:32 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 14:01 UTC (permalink / raw)
To: Alexandre Julliard
Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds
On Thu, Nov 16, 2006 at 12:34:27PM CET, Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > I would rather say "use 'git branch' to make sure if you are
> > ready to merge". Who teaches not to use "git pull"?
>
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.
How do those developers submit their changes? Do they push? If they do,
git-rebase can be saving one merge at most, and the merge is actually a
good thing (someone should write some nice standalone writeup about
that).
If they don't have push access and maintain their patches locally until
they get accepted, perhaps it would be far simpler for them to use
StGIT?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 14:01 ` Petr Baudis
@ 2006-11-16 15:48 ` Alexandre Julliard
0 siblings, 0 replies; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-16 15:48 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Theodore Tso, git, Nicolas Pitre, Linus Torvalds
Petr Baudis <pasky@suse.cz> writes:
> How do those developers submit their changes? Do they push? If they do,
> git-rebase can be saving one merge at most, and the merge is actually a
> good thing (someone should write some nice standalone writeup about
> that).
No, they use git-format-patch and mail them in.
> If they don't have push access and maintain their patches locally until
> they get accepted, perhaps it would be far simpler for them to use
> StGIT?
For regular developers, sure. But regular developers will need to
properly understand the git model anyway, and then they will able to
make sense even of the standard git commands ;-) The problem is that
there isn't a smooth progression to that point.
At first, a user will simply want to download and build the code, and
for that git-pull works great, it's a one-stop command to update their
tree.
Then after a while the user will fix a bug here and there, and at that
point git-rebase is IMO the best tool, it's reasonably easy to use,
doesn't require learning other commands, and once the patch is
accepted upstream it nicely gets the tree back to the state that the
user is familiar with.
The problem is that rebase doesn't work with pull, so the user needs
to un-learn git-pull and start using git-fetch; it's to avoid this
that we recommend using git-fetch from the start, which is unfortunate
since it makes things harder for beginners.
--
Alexandre Julliard
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:34 ` Alexandre Julliard
2006-11-16 14:01 ` Petr Baudis
@ 2006-11-17 13:32 ` Jakub Narebski
2006-11-17 16:49 ` Alexandre Julliard
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:32 UTC (permalink / raw)
To: git
Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> I would rather say "use 'git branch' to make sure if you are
>> ready to merge". Who teaches not to use "git pull"?
>
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.
What about proposed (and I think not accepted) merge strategy
"rebase" (formerly called "subordinate" or something like that)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 13:32 ` Jakub Narebski
@ 2006-11-17 16:49 ` Alexandre Julliard
2006-11-17 17:41 ` Jakub Narebski
0 siblings, 1 reply; 601+ messages in thread
From: Alexandre Julliard @ 2006-11-17 16:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Jakub Narebski <jnareb@gmail.com> writes:
> Alexandre Julliard wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>>> I would rather say "use 'git branch' to make sure if you are
>>> ready to merge". Who teaches not to use "git pull"?
>>
>> We do that for Wine. The problem is that we recommend using git-rebase
>> to make it easier for occasional developers to keep a clean history,
>> and rebase and pull interfere badly.
>
> What about proposed (and I think not accepted) merge strategy
> "rebase" (formerly called "subordinate" or something like that)?
That sounds very interesting. Has it ever been implemented, or only
discussed?
--
Alexandre Julliard
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 16:49 ` Alexandre Julliard
@ 2006-11-17 17:41 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 17:41 UTC (permalink / raw)
To: Alexandre Julliard, Junio C Hamano; +Cc: git
Alexandre Julliard wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Alexandre Julliard wrote:
>>> Junio C Hamano <junkio@cox.net> writes:
>>>
>>>> I would rather say "use 'git branch' to make sure if you are
>>>> ready to merge". Who teaches not to use "git pull"?
>>>
>>> We do that for Wine. The problem is that we recommend using git-rebase
>>> to make it easier for occasional developers to keep a clean history,
>>> and rebase and pull interfere badly.
>>
>> What about proposed (and I think not accepted) merge strategy
>> "rebase" (formerly called "subordinate" or something like that)?
>
> That sounds very interesting. Has it ever been implemented, or only
> discussed?
There was some implementation with warts
http://thread.gmane.org/gmane.comp.version-control.git/30068
Message-Id: <20061025155009.GD5591@parisc-linux.org>
which didn't got corrected and resent.
--
Jakub Narebski
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 4:21 ` Junio C Hamano
2006-11-16 11:34 ` Alexandre Julliard
@ 2006-11-16 16:07 ` Theodore Tso
2006-11-16 16:49 ` Theodore Tso
2006-11-22 23:21 ` Sanjoy Mahajan
1 sibling, 2 replies; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds
On Wed, Nov 15, 2006 at 08:21:36PM -0800, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
> > So with Bitkeeper, with "bk pull" there was never any question about
> > which branch ("line of development") you would be merging into after
> > doing a "bk pull", since there was only one LOD, and given that BK had
> > the rule that a within a LOD only one tip was allowed, a "bk pull"
> > _had_ to do do a merge operation.
>
> I've never used Bk and I really appreciate your comments here.
>
> > If you are operating on your local development branch, the reality is
> > that merging is probably not the right answer in the general case,
>
> I agree, but I wonder why you are pulling/fetching (with or
> without merge) if you are operating on your local development
> branch (implying that you are in the middle of something else).
Well, when I was using BitKeeper, I never would. Bitkeeper has what
Linus calls the broken "repository == branch" model. So normally I
would have one repository where I would track the upstream branch, and
only do bk pull into that branch. I would do my hacking in another
repository (i.e., branch), and periodically keep track wha was going
on in mainline by cd'ing to the mainline repository and doing the bk
pull there.
The challenge when you put multiple branches into a single repository,
is you have to keep track of which branch you happen to be in. In the
BK world, this was obvious because it would show up in my shell
prompt:
<tytso@candygram> {/usr/src/linux-2.6}
2%
(OK, obviously I'm in the Linux 2.6 upstream repository)
In a system where you need to keep track of what branch you are in via
an SCM-specific local state information, it's easy to get confused and
do a pull when you are in the "wrong" branch, or while you have local
state in your working directory.
What I currently do (and I'm sure I'm being really horrible and need
to be say 100 "Hail, Linus"'es for penance for not adhering staying in
the one true distributed state of grace) is that I keep an entirely
separate Linux 2.6 git repository just to make sure I never get
confused about what branch I might happen to be in when I do the "git
pull" --- and yeah, I could have used "git fetch", but 3+ years of BK
usage plus Hg usage is hard to get away from. I'm sure this is where
Linus would say that use of BK and Hg, causes permanent brain damage,
ala's Dijkstra's ofted quoted comment about use of Basic inducing
brain damage....
> I have to disagree with this. In the simplest CVS-like central
> repository with single branch setup in which many "novice users"
> start out with, there is almost no need for "git fetch" nor
> tracking branch. You pull, resolve conflicts, attempt to push
> back, perhaps gets "oh, no fast forward somebody pushed first",
> pull again, then push back. So I am not sure where "you really
> do not want to use pull. trust me" comes from.
I think the problem is the people who have had years of BK or Hg
experience. Maybe it's more of a documentation problem; perhaps a
"git for BK" or "git for Hg" users is what's needed. The problem
though is that while use of BK is definitely legacy, there are going
to be a lot of people who need to use both BK and Hg.
> It is a different story for people who _know_ git enough to know
> what is going on. They may be using multiple branches and
> interacting with multiple remote branches, and there are times
> you would want fetch and there are other times you would want
> pull. But for them, I do think the suggestion would never end
> with "trust me" -- they would understand what the differences
> are.
Well, I think this is where git's learning curve challenges are. Yes,
for users that are doing the stupidest, most simplistic usage models,
git is quite easy to use. And I am willing to grant that for people
who are using the deepest, most complicated and most distributed
development, who understand multiple branches and the index, and all
of the deep git plumbing, there's also no problem.
The challenge is in between; to use a car analogy, git has a great
automatic transmision, and an extremely powerful "racing clutch". But
for someone where the automatic transmission isn't good enough, when
as they start to learn how to use the manual transmission, git's
extremely touchy "racing clutch" is much more difficult master ---
especially in comparison to people who have learned to drive other,
more pedestrian "standard transmission" cars. So people who try to
use git's racing clutch keep stalling out the car, and some give up in
frustration.
And maybe the problem is one that should be addressed only by lots of
training, but at the moment, that's the reason why I believe a number
of projects have chosen Hg instead of git; they need more than the
"stupid simple" git usage, but if they don't need the extreme power of
git, Hg is simpler for people to learn how to use. The problem, of
course, comes when later on, the project finds out they really want
git's power, and now they have to deal with the repository conversion
as well as retraining their entire development community.
But hey, maybe this isn't a problem the git community wants to solve;
clearly git is optimized for the Linux kernel development, and maybe
it's too much to ask that it also work well for somewhat less
extremely distributed development models. But in any case, that's why
I chose Hg for e2fsprogs. At the time when I made my choice, git was
just too painful to learn how to use its more esoteric features, and
Hg was much closer to BK's model. (Since then, Hg has added more
functionality, including better multiple branches in a repository
support, and it's gotten more complicated, but it's still much simper
to teach someone how to use Hg than git.)
Regards,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:07 ` Theodore Tso
@ 2006-11-16 16:49 ` Theodore Tso
2006-11-22 23:21 ` Sanjoy Mahajan
1 sibling, 0 replies; 601+ messages in thread
From: Theodore Tso @ 2006-11-16 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre, Linus Torvalds
On Thu, Nov 16, 2006 at 11:07:00AM -0500, Theodore Tso wrote:
> I think the problem is the people who have had years of BK or Hg
> experience. Maybe it's more of a documentation problem; perhaps a
> "git for BK" or "git for Hg" users is what's needed. The problem
> though is that while use of BK is definitely legacy, there are going
> to be a lot of people who need to use both BK and Hg.
Err, what I meant to say is that there are going to be a lot of people
who will need to simultaneously use both git and Hg.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:07 ` Theodore Tso
2006-11-16 16:49 ` Theodore Tso
@ 2006-11-22 23:21 ` Sanjoy Mahajan
2006-11-24 11:29 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Sanjoy Mahajan @ 2006-11-22 23:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git, Nicolas Pitre, Linus Torvalds
The car analogy is excellently clear.
> they need more than the "stupid simple" git usage, but if they don't
> need the extreme power of git, Hg is simpler for people to learn how
> to use.
As a 80%-hg/20%-git user, I'm curious what features of git you had in
mind, so I know where to look as I wander up the git learning curve.
My experience with the git user interface, for what it's worth, is
that I never quite get the conceptual model crystal clear enough in my
head. So it won't stay for long enough for me to progress up the
learning curve and retain the gains. I move up a bit, but the gain
soon evaporates and I backslide, and then just hack my way through it.
I found hg's conceptual model very easy to learn, almost as if I don't
have to remember anything. Maybe that simplicity comes at a price,
whence my question at the start about the extreme-power features of
git.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-22 23:21 ` Sanjoy Mahajan
@ 2006-11-24 11:29 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-24 11:29 UTC (permalink / raw)
To: git
Sanjoy Mahajan wrote:
> The car analogy is excellently clear.
>
>> they need more than the "stupid simple" git usage, but if they don't
>> need the extreme power of git, Hg is simpler for people to learn how
>> to use.
>
> As a 80%-hg/20%-git user, I'm curious what features of git you had in
> mind, so I know where to look as I wander up the git learning curve.
>
> My experience with the git user interface, for what it's worth, is
> that I never quite get the conceptual model crystal clear enough in my
> head. So it won't stay for long enough for me to progress up the
> learning curve and retain the gains. I move up a bit, but the gain
> soon evaporates and I backslide, and then just hack my way through it.
>
> I found hg's conceptual model very easy to learn, almost as if I don't
> have to remember anything. Maybe that simplicity comes at a price,
> whence my question at the start about the extreme-power features of
> git.
As I never used Mercurial (hg), only read a bit about it and discussed on
#revctrl, I cannot say what features git has that hg has not, but I can
tell what powerfull git features differ from other SCM.
First, usually in other SCM the concept of branch is closely tied to the
concept of repository, perhaps allowing to share storage between branches
on the same local filesystem (on the same machine). In git, repository
holds DAG, the graph of revisions (of versions). Branches are "only" ways
to access this graph, and to extend it of the new commits. This makes git
more powerfull, but also perhaps unnecessary complicated if you deal with
single-branch repositories, or few-branch case. Additionally this
"complication" makes very clean model of repository - but you have to
understand it...
Second, the index. One might think that it is performance hack, but it
allows for commiting changes piece by piece and, what is more important,
a place form making merge in. Cogito (alternate Git UI/porcelain) tries to
hide index. By the way, I wonder how hg does merges without index to
provide place where do merges in...
Third, explicit/on-demand packing. This allows for the most (I think)
compression of all SCMs, and for the wire format to be the same as on-disk
format (with the addition that you can send thin packs on wire). As of now
no porcelain tries to hide it, although with the latest work allowing for
historical packs it would be easy to add this without significantly
affecting preformance.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
` (3 preceding siblings ...)
2006-11-16 1:14 ` Theodore Tso
@ 2006-11-16 1:20 ` Han-Wen Nienhuys
2006-11-16 1:53 ` Jakub Narebski
` (2 more replies)
2006-11-16 4:30 ` Petr Baudis
5 siblings, 3 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 1:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
> - git itself has now done it that way for the last 18 months, and the
> fact is, the people _complaining_ are a small subset of the people who
> actually use git on a daily basis and don't complain.
that's not a good argument; the set of git users is a small subset of
those that looked at git, and dismissed it because they couldn't wrap
their heads around it. It's worth trying to get those on board by
fixing the annoying little issues that have popped up in this thread.
The technical base for GIT is excellent, and the only reason for not
using it is its arcane interface.
A version control system is often only tangentially related to the real
work that needs to be done, so the incentive to learn it well is small,
and a steep learning curve only makes it worse.
FWIW, I regularly mess up with the differences between fetching, pulling
and merging. In particular, having to do a two step process to get
remote changes in,
git pull url-to-server master:master
..error message about not being a fast-forward..
git pull --update-head-ok url-to-server master:master
..still an error message about update not being a fast-forward..
(sigh)
git pull url-to-server master:scrap-branch
git pull . scrap-branch:my-current-branch
(make mental note of deleting scrap-branch)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 1:20 ` Han-Wen Nienhuys
@ 2006-11-16 1:53 ` Jakub Narebski
2006-11-16 2:03 ` Junio C Hamano
2006-11-16 3:12 ` Linus Torvalds
2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-16 1:53 UTC (permalink / raw)
To: git
Han-Wen Nienhuys wrote:
> FWIW, I regularly mess up with the differences between fetching, pulling
> and merging. In particular, having to do a two step process to get
> remote changes in,
>
> git pull url-to-server master:master
> ..error message about not being a fast-forward..
>
> git pull --update-head-ok url-to-server master:master
> ..still an error message about update not being a fast-forward..
What about:
git pull --update-head-ok url-to-server +master:master
(or --force, but be careful with that one)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 1:20 ` Han-Wen Nienhuys
2006-11-16 1:53 ` Jakub Narebski
@ 2006-11-16 2:03 ` Junio C Hamano
2006-11-16 2:30 ` Han-Wen Nienhuys
2006-11-16 3:12 ` Linus Torvalds
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 2:03 UTC (permalink / raw)
To: hanwen; +Cc: git
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> FWIW, I regularly mess up with the differences between fetching,
> pulling and merging. In particular, having to do a two step process
> to get remote changes in,
>
> git pull url-to-server master:master
> ..error message about not being a fast-forward..
>
> git pull --update-head-ok url-to-server master:master
> ..still an error message about update not being a fast-forward..
>
> (sigh)
Sigh indeed.
Why don't you do the simple and obvious
git pull url master
or "git pull url" if you already know the master is the branch
you are interested in.
The more advanced form of using tracking branches are there and
documentation talks about them for completeness but that does
not mean you have to use it.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 2:03 ` Junio C Hamano
@ 2006-11-16 2:30 ` Han-Wen Nienhuys
2006-11-16 3:27 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano escreveu:
>> FWIW, I regularly mess up with the differences between fetching,
>> pulling and merging. In particular, having to do a two step process
>> to get remote changes in,
>>
>> git pull url-to-server master:master
>> ..error message about not being a fast-forward..
>>
>> git pull --update-head-ok url-to-server master:master
>> ..still an error message about update not being a fast-forward..
>>
>> (sigh)
>
> Sigh indeed.
>
> Why don't you do the simple and obvious
>
> git pull url master
It is not all evident from the git-pull man-page that this is the
obvious and most common usage.
> or "git pull url" if you already know the master is the branch
> you are interested in.
Because I usually replace verbose commands with shortcuts only when I
understand exactly what the shortcut is.
To me it's very unlogical that
master:current-branch
doesn't work, but
master:
does work, and does what I'd expect
master:current-branch
to do. Interestingly, doing
pull ..url.. master:HEAD
also doesn't merge into the current branch, but rather creates a bogus
refs/heads/HEAD
I use the remote:local syntax, because I started using GIT in scripted
compiles from copied branches of remote repositories. There the explicit
remote:local statements are necessary because there is no default branch.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 2:30 ` Han-Wen Nienhuys
@ 2006-11-16 3:27 ` Junio C Hamano
2006-11-16 3:35 ` Junio C Hamano
2006-11-16 4:07 ` Junio C Hamano
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 3:27 UTC (permalink / raw)
To: hanwen; +Cc: git
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> Junio C Hamano escreveu:
>>...
>> Sigh indeed.
>>
>> Why don't you do the simple and obvious
>>
>> git pull url master
>
> It is not all evident from the git-pull man-page that this is the
> obvious and most common usage.
In the git user poll a few months ago, many people recommended
"everyday git" as a good cheat sheet, and indeed it does not
talk anything about directing the underlying git-fetch to
manipulate tracking branches by giving explicit refspec pairs to
git pull. You are obviously tripped by both the overeager
manpage (but manpage should strive to be complete so you cannot
really blame it) and less than optimally organized tutorial
style documents.
I myself do prefer, when learning a new tool, to use longhand
until I understand the shorthand, but that attitude requires a
true commitment to learn the tool, and most people do not go
that route. Tutorial style documents tend to give the commonly
used shorthand first for that exact reason.
Shorthand to give only the branch name to fetch and merge
immediately without using a tracking branch is equivalent to
longhand "branch:" as you found out, so if that was what was
desired then people with the attitude "before understanding what
longhand does I prefer using shorthand" like myself and you
would have liked to learn "git pull url branch:" notation from
Tutorial. But I think we _are_ minority. People would not want
to see that seemingly useless colon there.
> To me it's very unlogical that
>
> master:current-branch
>
> doesn't work,
That shows that you did not understand what fetch does. Maybe
you do now, but a very natural consequence of directing fetch to
update tracking branches with the colon notation is:
- "pull url master:master", while on master, is almost always
wrong and not something you would want to do, ever.
"fetch --update-head-ok url +master:master; reset --hard HEAD"
may make sense but never "pull".
> I use the remote:local syntax, because I started using GIT in scripted
> compiles from copied branches of remote repositories. There the
> explicit remote:local statements are necessary because there is no
> default branch.
If you perhaps wanted to ask "is there a better way to do what
I've been doing?", then I am willing to think with you to come
up with an answer. Unfortunately, however, I do not understand
the above paragraph, so I'd refrain from commenting on it in
this response.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:27 ` Junio C Hamano
@ 2006-11-16 3:35 ` Junio C Hamano
2006-11-16 4:07 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 3:35 UTC (permalink / raw)
To: hanwen; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
(not changing what I said but editorial)
> I myself do prefer, when learning a new tool, to use longhand
> until I understand the shorthand, but that attitude requires a
> true commitment to learn the tool, and most people do not go
> that route. Tutorial style documents tend to give the commonly
> used shorthand first for that exact reason.
Eh, sorry, "prefer to use longhand until I understand what is
going on before using the shorthand" is what I wanted to say.
> Shorthand to give only the branch name to fetch and merge
> immediately without using a tracking branch is equivalent to
> longhand "branch:" as you found out, so if that was what was
> desired then people with the attitude "before understanding what
> longhand does I prefer using shorthand" like myself and you
"prefer not using shorthand", sorry again.
> would have liked to learn "git pull url branch:" notation from
> Tutorial. But I think we _are_ minority. People would not want
> to see that seemingly useless colon there.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:27 ` Junio C Hamano
2006-11-16 3:35 ` Junio C Hamano
@ 2006-11-16 4:07 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 4:07 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> Junio C Hamano escreveu:
>>>...
>>> Sigh indeed.
>>>
>>> Why don't you do the simple and obvious
>>>
>>> git pull url master
>>
>> It is not all evident from the git-pull man-page that this is the
>> obvious and most common usage.
>
> In the git user poll a few months ago, many people recommended
> "everyday git" as a good cheat sheet, and indeed it does not
> talk anything about ...
Sorry, I must have been very grumpy mood when I wrote the
message (cf. Pasky's utterance on #git a few days ago). What I
wrote was a bit incoherent, so here is an attempt to clarify.
I should point out that the colon separated refspec pairs you
can give to "pull" was designed with considerable thought; it is
not a convenience hack that we give them to "pull" that "fetches
and merges". Linus's and Michael's other messages in this
thread may seem to be saying that using tracking branches is not
a kosher way to use git, but I do not think that is a correct
interpretation of their messages.
The workflow that does not use any tracking branches is the
simplest and truly distributed way as Linus says. The command
recommended in "everyday git" document:
git pull $url $branchname
is the most natural way to express it, and simplest variant that
you do not have to say anything "colon" in it.
However that does not mean it is a bad practice to use tracking
branches. Sometimes it is handy to be able to refer to what you
fetched from the remote the last time, possibly which is what
you merged into your branch if that last fetch was done via "git
pull", so that you can later examine its history without your
own development. For that purpose, you need to store what you
fetched in your local refs/ namespace, and that is what tracking
branches are.
The workflow that fetches to tracking branches and then merges
within local repository as two separate steps loses the true
origin information ("Merge branch 'foo'" vs "Merge branch 'foo'
of git://git.bar.xz/foo.git"). That's the reason why not just
"git fetch" but also "git pull" take the colon separated refspec
pairs to direct git to update the tracking branches when "pull"
happenes. The longhands are cumbersome to type all the time,
and we have shorthand, both to store URL: and Pull: lines in
remotes/ hierarchy, and also $branchname alone is a shorthand
for saying "${branchname}:", meaning "do not use a tracking
branch to store this".
So you have options to use or not to use tracking branches.
After cloning we happen to default to track all remote branches
with corresponding local tracking branches, but that is only
because may people on the list wanted to make life easier to CVS
migrants where following mostly static set of branches is the
norm ("set" is the static part: I do not mean the branches stay
still) and we wanted to make it easier for them.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 1:20 ` Han-Wen Nienhuys
2006-11-16 1:53 ` Jakub Narebski
2006-11-16 2:03 ` Junio C Hamano
@ 2006-11-16 3:12 ` Linus Torvalds
2006-11-16 10:31 ` Junio C Hamano
` (2 more replies)
2 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 3:12 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> Linus Torvalds escreveu:
> > - git itself has now done it that way for the last 18 months, and the
> > fact is, the people _complaining_ are a small subset of the people who
> > actually use git on a daily basis and don't complain.
>
>
> that's not a good argument; the set of git users is a small subset of those
> that looked at git, and dismissed it because they couldn't wrap their heads
> around it.
And I've said this again, and I'll say it once more: that has basically
_nothing_ to do with whether you spell "pull" as "pull" or "merge".
The reason people have trouble wrapping their heads around git is because
they have been braindamaged by CVS and SVN, and just don't understand the
fairly fundamental new concepts and workflow.
That's totally different from then arguing about stupid naming issues.
Peopel seem to believe that changign a few names or doing other totally
_minimal_ UI changes would somehow magically make things understandable. I
claim that isn't so at all. The fact is, git is different from CVS and
SVN, and git _has_ to be different from CVS and SVN. It has to be
different because the whole model of CVS and SVN is simpyl fundamentally
BROKEN.
> It's worth trying to get those on board by fixing the annoying
> little issues that have popped up in this thread.
I claim that those "annoying little issues" are totally made up by people
who had trouble wrapping their minds about git, and then make up reasons
that have nothing to do with reality for why that might be so.
Let's face it, you could just alias "merge" to "pull", and it wouldn't
really change ANYTHING. You'd still have to learn the new model.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:12 ` Linus Torvalds
@ 2006-11-16 10:31 ` Junio C Hamano
2006-11-16 10:45 ` Han-Wen Nienhuys
2006-11-16 23:00 ` Johannes Schindelin
2 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Han-Wen Nienhuys
Linus Torvalds <torvalds@osdl.org> writes:
> And I've said this again, and I'll say it once more: that has basically
> _nothing_ to do with whether you spell "pull" as "pull" or "merge".
>
> The reason people have trouble wrapping their heads around git is because
> they have been braindamaged by CVS and SVN, and just don't understand the
> fairly fundamental new concepts and workflow.
> ...
> Let's face it, you could just alias "merge" to "pull", and it wouldn't
> really change ANYTHING. You'd still have to learn the new model.
I had a bit different feeling about yesterday's discussion
myself.
If somebody uses git like you do in "truly distributed way", the
current pull behaviour and pull being an operational mirror to
push are natural consequence of the model and concepts, and
there is nothing to fix (modulo "the default merge source per
branch" should be made easier to use). Renaming the pull to
merge would not make it any easier to use unless the underlying
model is understood, and I fully agree with you on that.
But for people working in a project organized around central
repository in the CVS/SVN fashion, the workflow is quite
different. CVS does not even let you "fetch" without either
merging (co) or throwing away your work (co -C), and we already
do support that model with:
git clone
git pull
work work work; git commit
git push
: oops not fast forward?
git pull
resolve work; git commit
git push
without ever using a local branch, any tracking branch, nor
use of git-fetch. So we do support both extremes ("truly
distributed" and "not distributed at all") reasonably well.
The trouble starts when the users hear about this wonderful
"distributed" stuff git offers, and try to use it without
understanding the key concepts. People tend to learn by doing
and there is a leap the user need to make because now they need
to understand branched development, branches and fetching like
you explained if they want to use git the same way as you do.
Once they understand them, then the current set of tools offer
them a simple and very straightforward user interface (the tools
directly reflect the concepts and it is straightforward only
because we are talking about users who understood the concepts).
But we have to admit that this leap may rather be difficult for
people who are used to other models. Telling them that our
model is different and it is different for a good reason does
not change the fact that the more different something is, the
more difficult to learn it.
I suspect that there could be a way to use git, not like you or
I do. Our workflows are already quite different (e.g. you
almost never do topic branch merge yourself in your repository,
but I have abundance of them). There is no reason to think
there won't be other workflows that are suitable for other
people. Some workflows might be classified less distributed and
inferiour compared to the "truly git way" from "truly
distributed is the point of git" point of view, but nevertheless
could be "good enough" for those people. In other words, a
workflow that is a bit more advanced than just a single trunk
CVS/SVN usage could still take advantage of some of the features
to support distributed development model git has, while not
taking full advantage of truly distributed nature of git.
I think the complaints in the yesterday's discussion are mostly
about frustration that, while we have a reasonable support for
the both extremes, we do not either know what that middle ground
workflow is, or even if we know what that is, we do not support
it very well.
And I am not opposed to people exploring what that different
workflow would be, and while they do so if they come up with a
set of commands (get/put perhaps) to suppor that slightly
different workflow, that would be a very good thing.
Add foreign SCM importers in the mix and the situation becomes
more difficult and interesting. cvsimport mostly works and
quacks like git-fetch with set of tracking branches, which I
think is the right model for the importers, and would integrate
well with the current set of tools. I believe svnimport is the
same way. But I do not know about git-svn.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:12 ` Linus Torvalds
2006-11-16 10:31 ` Junio C Hamano
@ 2006-11-16 10:45 ` Han-Wen Nienhuys
2006-11-16 11:11 ` Junio C Hamano
2006-11-16 16:23 ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 23:00 ` Johannes Schindelin
2 siblings, 2 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 10:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
>>> - git itself has now done it that way for the last 18 months, and the
>>> fact is, the people _complaining_ are a small subset of the people who
>>> actually use git on a daily basis and don't complain.
>>
>> that's not a good argument; the set of git users is a small subset of those
>> that looked at git, and dismissed it because they couldn't wrap their heads
>> around it.
>
> And I've said this again, and I'll say it once more: that has basically
> _nothing_ to do with whether you spell "pull" as "pull" or "merge".
>
> The reason people have trouble wrapping their heads around git is because
> they have been braindamaged by CVS and SVN, and just don't understand the
> fairly fundamental new concepts and workflow.
> I claim that those "annoying little issues" are totally made up by
> people
> who had trouble wrapping their minds about git, and then make up
> reasons
> that have nothing to do with reality for why that might be so.
Let me put this more personally: I continue to be bitten by stupid
naming issues, and the myriad of little mostly non-orthogonal commands.
My head is doing just fine otherwise, and has no problems wrapping it
around the core of GIT. I've also used Darcs for almost a year. Darcs,
which is much less overwhelming.
This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs
as an example.
The following
mkdir x y
cd x
hg init
echo hoi > bla
hg add
hg commit -m 'yes, I am also too stupid to refuse explicit empty
commit messages'
cd ../y
hg init
hg pull ../x
pretty much works the same in Darcs, bzr and mercurial.
With GIT, this is what happens
[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?
[hanwen@haring y]$ git fetch ../x
warning: no common commits
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
100% (3/3) done
Total 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
100% (3/3) done
[hanwen@haring y]$ git checkout
fatal: ambiguous argument 'HEAD': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name HEAD
[hanwen@haring y]$ git branch master
fatal: Needed a single revision
at this point, I resort to adding a bogus commit and/or editing
.git/HEAD by hand. I'm sure there is a saner way of doing it, but I
still haven't found out what it is.
This might not be typical GIT use, but it does show the typical GIT user
experience, at least mine.
If you want to have another example of how not to design a
user-interface, try the above on Monotone.
> That's totally different from then arguing about stupid naming issues.
>
> Peopel seem to believe that changign a few names or doing other totally
> _minimal_ UI changes would somehow magically make things understandable. I
> claim that isn't so at all. The fact is, git is different from CVS and
> SVN, and git _has_ to be different from CVS and SVN. It has to be
> different because the whole model of CVS and SVN is simpyl fundamentally
> BROKEN.
>
>> It's worth trying to get those on board by fixing the annoying
>> little issues that have popped up in this thread.
>
>
> Let's face it, you could just alias "merge" to "pull", and it wouldn't
> really change ANYTHING.
I don't want ANYTHING to really change, I just want a sane interface to it.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 10:45 ` Han-Wen Nienhuys
@ 2006-11-16 11:11 ` Junio C Hamano
2006-11-16 11:47 ` Junio C Hamano
2006-11-16 13:03 ` Han-Wen Nienhuys
2006-11-16 16:23 ` Cleaning up git user-interface warts Linus Torvalds
1 sibling, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 11:11 UTC (permalink / raw)
To: hanwen; +Cc: git
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
You claim it is _an interface_ issue but it is not.
> With GIT, this is what happens
>
> [hanwen@haring y]$ git pull ../x
> fatal: Needed a single revision
> Pulling into a black hole?
You asked it to fetch from the neighbour repository and merge it
into your current branch which does not exist (I presume that
you omitted to describe what you did in directory y/ and I am
assuming you did "mkdir y && cd y && git initdb" and nothing
else). You are pulling into a black hole.
> [hanwen@haring y]$ git fetch ../x
>...
> [hanwen@haring y]$ git checkout
You fetched without telling it in which tracking branch to store
what you fetched, and as a result your HEAD is not updated, so
your current branch still does not exist. A failure from
checking out nothingness is not an interface issue; expectation
for it to work is a concept level issue.
> [hanwen@haring y]$ git branch master
> fatal: Needed a single revision
You are not at any commit yet and you try to create a branch?
Of course, the "right" (in some sense of the word) thing is to
do "git clone x y" in the parent directory, without creating y
upfront.
If you have an empty y to begin with, then you can do this:
$ git fetch ../x :origin
$ git reset --hard origin
which would mirror a part of what "git clone" would have done
for you. It copies from the other repository, stores the tip in
your tracking branch called "origin", and make your HEAD to be
the same as origin. After these two commands, you would have
two branches, origin and master, and you will be on master.
You can name 'origin' any way you want. You might want to name
it 'x' to make it clear (to yourself) that it is used to track
what will happen in the neighboring repository 'x'. Also, you
would most likely be fetching and merging from the same ../x
from now on, so it might be handy to set up the remotes for it:
$ cat >.git/remotes/x <<EOF
URL: ../x
Pull: master:origin
EOF
Then subsequent work of yours would be done on 'master' branch
(you have only two branches, and origin is a tracking branch so
you will never make commits on it, which means the above is a
logical consequence), and from time to time you would sync with
whoever is working in ../x
$ git pull x
Here, 'x' is just a shorthand which looks up the URL: and Pull: line
through .git/remotes/x. If your .git/remotes/ file was named origin
(not x), you could even have written:
$ git pull
because pull defaults to 'origin' (without any other configuration).
>> Let's face it, you could just alias "merge" to "pull", and it
>> wouldn't really change ANYTHING.
>
> I don't want ANYTHING to really change, I just want a sane interface to it.
I agree that you do not want to change anything. You just
needed a bit of handholding, because you deviated from the
cookbook usage, to correct your course.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:11 ` Junio C Hamano
@ 2006-11-16 11:47 ` Junio C Hamano
2006-11-20 19:44 ` Horst H. von Brand
2006-11-16 13:03 ` Han-Wen Nienhuys
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 11:47 UTC (permalink / raw)
To: hanwen; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?
Having said all that, I happen to think that this particular
case of pulling into void could deserve to be special cased to
pretend it is a fast forward (after all, nothingness is an
ancestor of anything), if only to make new people's first
experience more pleasant.
Working from nothingness is something not usually done in
everyday work, so from practical and technical point of view it
does not add much _real_ value to the people who actually uses
the system, but nevertheless, new people typically start
learning the system from either cloned repository (which I
believe is covered by the existing tools fairly well) or
emptiness (which bitten us here in a bad way), and making the
first experience more pleasnt to new people have a positive
value of flattening the learning curve.
So please consider that this is classified as a bug.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:47 ` Junio C Hamano
@ 2006-11-20 19:44 ` Horst H. von Brand
2006-11-20 19:46 ` Shawn Pearce
2006-11-20 20:02 ` Jakub Narebski
0 siblings, 2 replies; 601+ messages in thread
From: Horst H. von Brand @ 2006-11-20 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: hanwen, git
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> >
> >> [hanwen@haring y]$ git pull ../x
> >> fatal: Needed a single revision
> >> Pulling into a black hole?
>
> Having said all that, I happen to think that this particular
> case of pulling into void could deserve to be special cased to
> pretend it is a fast forward (after all, nothingness is an
> ancestor of anything), if only to make new people's first
> experience more pleasant.
If you make pushing into an empty repository work also, you fix the case of
"create an empty repo for somebody, let them fill it up remotely later".
[...]
> So please consider that this is classified as a bug.
Thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-20 19:44 ` Horst H. von Brand
@ 2006-11-20 19:46 ` Shawn Pearce
2006-11-20 20:02 ` Jakub Narebski
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-20 19:46 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Junio C Hamano, hanwen, git
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".
This seems to work just fine now. I do it all of the time.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-20 19:44 ` Horst H. von Brand
2006-11-20 19:46 ` Shawn Pearce
@ 2006-11-20 20:02 ` Jakub Narebski
1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-20 20:02 UTC (permalink / raw)
To: git
Horst H. von Brand wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>>>
>>>> [hanwen@haring y]$ git pull ../x
>>>> fatal: Needed a single revision
>>>> Pulling into a black hole?
>>
>> Having said all that, I happen to think that this particular
>> case of pulling into void could deserve to be special cased to
>> pretend it is a fast forward (after all, nothingness is an
>> ancestor of anything), if only to make new people's first
>> experience more pleasant.
>
> If you make pushing into an empty repository work also, you fix the case of
> "create an empty repo for somebody, let them fill it up remotely later".
That was only the _pull_ which didn't work in empty repo.
Fetch and push worked (and work) just fine with empty repo.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 11:11 ` Junio C Hamano
2006-11-16 11:47 ` Junio C Hamano
@ 2006-11-16 13:03 ` Han-Wen Nienhuys
2006-11-16 13:11 ` Han-Wen Nienhuys
2006-11-17 13:25 ` Jakub Narebski
1 sibling, 2 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 13:03 UTC (permalink / raw)
To: git; +Cc: git
Junio C Hamano escreveu:
> You claim it is _an interface_ issue but it is not.
>> I don't want ANYTHING to really change, I just want a sane interface
>> to it.
>
> I agree that you do not want to change anything. You just
> needed a bit of handholding, because you deviated from the
> cookbook usage, to correct your course.
Users (well, I do at least) start fiddling with systems to find out how
they work. Reading the manual is usually done as a last resort. I
think this is pretty well documented in usability research.
I'm trying to show how GIT is badly suited to this. Your response is to
explain to me what I should have done. That's nice, but that approach
doesn't scale, because you don't reach the dozens of users out there who
try the same, fail and give up.
If you really want to find out the weaknesses, you'd have to sit someone
new to git in front of a computer, and let him figure how to operate it,
while videotaping everything.
Writing a manual for newbies is also an effective (and simpler and
cheaper) approach of figuring out what needs to be changed.
As another example: annoyances regarding program invocation
- option handling: -x -f -z != -xfz , "--max-count 1" doesn't work,
but needs an '='
- git --help lists an unordered set, which is too long scan quickly.
I'd expect that list to either contain everything or the minimum set for
daily use. I.e. the set introduced in a first tutorial. Why are merge,
prune, verify-tag there?
Try "bzr help" for comparison.
- --pretty option with wholly uninformative options full, medium,
short, raw. It's not even documented what each option does.
I can go on with listing idiosyncrasies, but my point is not to get help
from you, but rather to show how git can be improved.
>> With GIT, this is what happens
>>
>> [hanwen@haring y]$ git pull ../x
>> fatal: Needed a single revision
>> Pulling into a black hole?
>
> You asked it to fetch from the neighbour repository and merge it
> into your current branch which does not exist (I presume that
> you omitted to describe what you did in directory y/ and I am
> assuming you did "mkdir y && cd y && git initdb" and nothing
> else). You are pulling into a black hole.
as you remark in the other reply, there is IMO no reason for not having
an empty 'master' branch. If master + HEAD gets created on the first
commit, it might as well be created on the init-db.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 13:03 ` Han-Wen Nienhuys
@ 2006-11-16 13:11 ` Han-Wen Nienhuys
2006-11-17 13:25 ` Jakub Narebski
1 sibling, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 13:11 UTC (permalink / raw)
To: git
Han-Wen Nienhuys escreveu:
> I can go on with listing idiosyncrasies, but my point is not to get help
> from you, but rather to show how git can be improved.
oh, and another annoying one: git's insistence on firing up a pager if
there is nothing to page, eg. try
git-log je-n-existe-pas
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 13:03 ` Han-Wen Nienhuys
2006-11-16 13:11 ` Han-Wen Nienhuys
@ 2006-11-17 13:25 ` Jakub Narebski
2006-11-24 12:26 ` Han-Wen Nienhuys
1 sibling, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 13:25 UTC (permalink / raw)
To: git
Han-Wen Nienhuys wrote:
> As another example: annoyances regarding program invocation
>
> - option handling: -x -f -z != -xfz , "--max-count 1" doesn't work,
> but needs an '='
That's true, and the probable cause is that git tries to first, avoid
dependency on options parsers like getopt/getopt_long/argp or popt for
commands in C, getopt for commands in shell, Getopt::Std/Getopt::Long for
commands in Perl, and something for commands in Python (if there are any
left); second, existing options parsers do not deal (I think) with
distinction between arguments to wrapper and arguments to command, '--' to
separate revisions from pathnames not options from arguments, and the whole
revisions and revision list specifying syntax (where "a --not b" is not
equivalent to "--not a b").
That said, perhaps we should craft our own options parsing (or modify
existing one)...
> - git --help lists an unordered set, which is too long scan quickly.
It is one page of alphabetically ordered commands.
git(7) gives whole list of commands, divided into categories, by the way.
> I'd expect that list to either contain everything or the minimum set for
> daily use. I.e. the set introduced in a first tutorial. Why are merge,
> prune, verify-tag there?
>
> Try "bzr help" for comparison.
I wonder why "repack" isn't there, if "prune" is.
> - --pretty option with wholly uninformative options full, medium,
> short, raw. It's not even documented what each option does.
And 'oneline' and undocumented 'email'. True, git lacks documentation (and
this one of main complaints in git survey).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 13:25 ` Jakub Narebski
@ 2006-11-24 12:26 ` Han-Wen Nienhuys
2006-11-24 12:41 ` Jakub Narebski
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-24 12:26 UTC (permalink / raw)
To: git
Jakub Narebski escreveu:
>> - --pretty option with wholly uninformative options full, medium,
>> short, raw. It's not even documented what each option does.
>
> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
> this one of main complaints in git survey).
The recently posted patch documenting is an improvement, but why not
add an option so you can do
--format 'committer %c\nauthor %a\n'
this catches all combinations, and is easier for scripting.
Right now, I have some scripts that have to munge log output with
regular expressions to strip out the "author:" prefixes.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-24 12:26 ` Han-Wen Nienhuys
@ 2006-11-24 12:41 ` Jakub Narebski
2006-12-05 22:42 ` Johannes Schindelin
2007-02-23 0:35 ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
2 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-24 12:41 UTC (permalink / raw)
To: git
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>
>>> - --pretty option with wholly uninformative options full, medium,
>>> short, raw. It's not even documented what each option does.
>>
>> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
>> this one of main complaints in git survey).
>
> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
>
> --format 'committer %c\nauthor %a\n'
>
> this catches all combinations, and is easier for scripting.
>
> Right now, I have some scripts that have to munge log output with
> regular expressions to strip out the "author:" prefixes.
If we ever implemented this, I'd rather to separate what is now of format
parsing in git-for-each-ref (although I'd like to make it more like rpm's
--query-format argument, with %-n{header}, %[array] etc.) into separate
module, and reuse it for git-log and friends --pretty/--format handling.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-24 12:26 ` Han-Wen Nienhuys
2006-11-24 12:41 ` Jakub Narebski
@ 2006-12-05 22:42 ` Johannes Schindelin
2006-12-05 22:58 ` Junio C Hamano
2007-02-23 0:35 ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-12-05 22:42 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
Hi,
On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
>
> --format 'committer %c\nauthor %a\n'
>
> this catches all combinations, and is easier for scripting.
Yes, it would be easier for scripting, and it would probably be relatively
easy, what with the addition of interpolate.[ch] to git. However, it is
work, and I am lazy.
What information would you like, anyway? IOW can you provide me with a
list like this:
%c committer
%a author
%d committer_date
...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-12-05 22:42 ` Johannes Schindelin
@ 2006-12-05 22:58 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-12-05 22:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Han-Wen Nienhuys
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
>
>> The recently posted patch documenting is an improvement, but why not
>> add an option so you can do
>>
>> --format 'committer %c\nauthor %a\n'
>>
>> this catches all combinations, and is easier for scripting.
>
> Yes, it would be easier for scripting, and it would probably be relatively
> easy, what with the addition of interpolate.[ch] to git. However, it is
> work, and I am lazy.
Lazy is good when the details should not matter. If some people
are scripting, they are fully capable of reading raw or fuller.
^ permalink raw reply [flat|nested] 601+ messages in thread
* [PATCH for "next"] pretty-formats: add 'format:<string>'
2006-11-24 12:26 ` Han-Wen Nienhuys
2006-11-24 12:41 ` Jakub Narebski
2006-12-05 22:42 ` Johannes Schindelin
@ 2007-02-23 0:35 ` Johannes Schindelin
2007-02-23 1:03 ` Han-Wen Nienhuys
2007-02-23 6:21 ` Junio C Hamano
2 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 0:35 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git, junkio
With this patch,
$ git show -s \
--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
shows something like
Ze komit 04c5c88 woss
dunn buy ze great Junio C Hamano
The supported placeholders are:
'%H': commit hash
'%h': abbreviated commit hash
'%T': tree hash
'%t': abbreviated tree hash
'%P': parent hashes
'%p': abbreviated parent hashes
'%an': author name
'%ae': author email
'%ad': author date
'%aD': author date, RFC2822 style
'%ar': author date, relative
'%at': author date, UNIX timestamp
'%cn': committer name
'%ce': committer email
'%cd': committer date
'%cD': committer date, RFC2822 style
'%cr': committer date, relative
'%ct': committer date, UNIX timestamp
'%e': encoding
'%s': subject
'%b': body
'%Cred': switch color to red
'%Cgreen': switch color to green
'%Cblue': switch color to blue
'%Creset': reset color
'%n': newline
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
> The recently posted patch documenting is an improvement, but why
> not add an option so you can do
>
> --format 'committer %c\nauthor %a\n'
>
> this catches all combinations, and is easier for scripting.
So, I overcame my laziness after 91 days...
Of course, this is not as efficient as it could be: it _will_ get
_all_ variables from the commit, even if not needed. However, I
don't think that it matters in reality.
BTW I have not found any implementation of xstrndup(), so I let it
be static.
Documentation/pretty-formats.txt | 44 +++++++++
commit.c | 195 ++++++++++++++++++++++++++++++++++++++
commit.h | 1 +
log-tree.c | 2 +-
4 files changed, 241 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index fb0b0b9..2fe6c31 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -77,9 +77,53 @@ displayed in full, regardless of whether --abbrev or
true parent commits, without taking grafts nor history
simplification into account.
+ * 'format:'
++
+The 'format:' format allows you to specify which information
+you want to show. It works a little bit like printf format,
+with the notable exception that you get a newline with '%n'
+instead of '\n'.
+
+E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<"'
+would show something like this:
+
+The author of fe6e0ee was Junio C Hamano, 23 hours ago
+The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
+
+The placeholders are:
+
+- '%H': commit hash
+- '%h': abbreviated commit hash
+- '%T': tree hash
+- '%t': abbreviated tree hash
+- '%P': parent hashes
+- '%p': abbreviated parent hashes
+- '%an': author name
+- '%ae': author email
+- '%ad': author date
+- '%aD': author date, RFC2822 style
+- '%ar': author date, relative
+- '%at': author date, UNIX timestamp
+- '%cn': committer name
+- '%ce': committer email
+- '%cd': committer date
+- '%cD': committer date, RFC2822 style
+- '%cr': committer date, relative
+- '%ct': committer date, UNIX timestamp
+- '%e': encoding
+- '%s': subject
+- '%b': body
+- '%Cred': switch color to red
+- '%Cgreen': switch color to green
+- '%Cblue': switch color to blue
+- '%Creset': reset color
+- '%n': newline
+
+
--encoding[=<encoding>]::
The commit objects record the encoding used for the log message
in their encoding header; this option can be used to tell the
command to re-code the commit log message in the encoding
preferred by the user. For non plumbing commands this
defaults to UTF-8.
+
diff --git a/commit.c b/commit.c
index 8d279b0..a97aef3 100644
--- a/commit.c
+++ b/commit.c
@@ -3,6 +3,7 @@
#include "commit.h"
#include "pkt-line.h"
#include "utf8.h"
+#include "interpolate.h"
int save_commit_buffer = 1;
@@ -36,8 +37,11 @@ struct cmt_fmt_map {
{ "full", 5, CMIT_FMT_FULL },
{ "fuller", 5, CMIT_FMT_FULLER },
{ "oneline", 1, CMIT_FMT_ONELINE },
+ { "format:", 7, CMIT_FMT_USERFORMAT},
};
+static char *user_format;
+
enum cmit_fmt get_commit_format(const char *arg)
{
int i;
@@ -46,6 +50,12 @@ enum cmit_fmt get_commit_format(const char *arg)
return CMIT_FMT_DEFAULT;
if (*arg == '=')
arg++;
+ if (!prefixcmp(arg, "format:")) {
+ if (user_format)
+ free(user_format);
+ user_format = xstrdup(arg + 7);
+ return CMIT_FMT_USERFORMAT;
+ }
for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len) &&
!strncmp(arg, cmt_fmts[i].n, strlen(arg)))
@@ -710,6 +720,188 @@ static char *logmsg_reencode(const struct commit *commit,
return out;
}
+static char *xstrndup(const char *text, int len)
+{
+ char *result = xmalloc(len + 1);
+ memcpy(result, text, len);
+ result[len] = '\0';
+ return result;
+}
+
+static void fill_person(struct interp *table, const char *msg, int len)
+{
+ int start, end, tz = 0;
+ unsigned long date;
+ char *ep;
+
+ /* parse name */
+ for (end = 0; end < len && msg[end] != '<'; end++)
+ ; /* do nothing */
+ start = end + 1;
+ while (end > 0 && isspace(msg[end - 1]))
+ end--;
+ table[0].value = xstrndup(msg, end);
+
+ if (start >= len)
+ return;
+
+ /* parse email */
+ for (end = start + 1; end < len && msg[end] != '>'; end++)
+ ; /* do nothing */
+
+ if (end >= len)
+ return;
+
+ table[1].value = xstrndup(msg + start, end - start);
+
+ /* parse date */
+ for (start = end + 1; start < len && isspace(msg[start]); start++)
+ ; /* do nothing */
+ if (start >= len)
+ return;
+ date = strtoul(msg + start, &ep, 10);
+ if (msg + start == ep)
+ return;
+
+ table[5].value = xstrndup(msg + start, ep - msg + start);
+
+ /* parse tz */
+ for (start = ep - msg + 1; start < len && isspace(msg[start]); start++)
+ ; /* do nothing */
+ if (start + 1 < len) {
+ tz = strtoul(msg + start + 1, NULL, 10);
+ if (msg[start] == '-')
+ tz = -tz;
+ }
+
+ interp_set_entry(table, 2, show_date(date, tz, 0));
+ interp_set_entry(table, 3, show_rfc2822_date(date, tz));
+ interp_set_entry(table, 4, show_date(date, tz, 1));
+}
+
+static long format_commit_message(const struct commit *commit,
+ const char *msg, char *buf, unsigned long space)
+{
+ struct interp table[] = {
+ { "%H" }, /* commit hash */
+ { "%h" }, /* abbreviated commit hash */
+ { "%T" }, /* tree hash */
+ { "%t" }, /* abbreviated tree hash */
+ { "%P" }, /* parent hashes */
+ { "%p" }, /* abbreviated parent hashes */
+ { "%an" }, /* author name */
+ { "%ae" }, /* author email */
+ { "%ad" }, /* author date */
+ { "%aD" }, /* author date, RFC2822 style */
+ { "%ar" }, /* author date, relative */
+ { "%at" }, /* author date, UNIX timestamp */
+ { "%cn" }, /* committer name */
+ { "%ce" }, /* committer email */
+ { "%cd" }, /* committer date */
+ { "%cD" }, /* committer date, RFC2822 style */
+ { "%cr" }, /* committer date, relative */
+ { "%ct" }, /* committer date, UNIX timestamp */
+ { "%e" }, /* encoding */
+ { "%s" }, /* subject */
+ { "%b" }, /* body */
+ { "%Cred" }, /* red */
+ { "%Cgreen" }, /* green */
+ { "%Cblue" }, /* blue */
+ { "%Creset" }, /* reset color */
+ { "%n" } /* newline */
+ };
+ enum interp_index {
+ IHASH = 0, IHASH_ABBREV,
+ ITREE, ITREE_ABBREV,
+ IPARENTS, IPARENTS_ABBREV,
+ IAUTHOR_NAME, IAUTHOR_EMAIL,
+ IAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,
+ IAUTHOR_TIMESTAMP,
+ ICOMMITTER_NAME, ICOMMITTER_EMAIL,
+ ICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,
+ ICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,
+ IENCODING,
+ ISUBJECT,
+ IBODY,
+ IRED, IGREEN, IBLUE, IRESET_COLOR,
+ INEWLINE
+ };
+ struct commit_list *p;
+ char parents[1024];
+ int i;
+ enum { HEADER, SUBJECT, BODY } state;
+
+ if (INEWLINE + 1 != ARRAY_SIZE(table))
+ die("invalid interp table!");
+
+ /* these are independent of the commit */
+ interp_set_entry(table, IRED, "\033[31m");
+ interp_set_entry(table, IGREEN, "\033[32m");
+ interp_set_entry(table, IBLUE, "\033[34m");
+ interp_set_entry(table, IRESET_COLOR, "\033[m");
+ interp_set_entry(table, INEWLINE, "\n");
+
+ /* these depend on the commit */
+ if (!commit->object.parsed)
+ parse_object(commit->object.sha1);
+ interp_set_entry(table, IHASH, sha1_to_hex(commit->object.sha1));
+ interp_set_entry(table, IHASH_ABBREV,
+ find_unique_abbrev(commit->object.sha1,
+ DEFAULT_ABBREV));
+ interp_set_entry(table, ITREE, sha1_to_hex(commit->tree->object.sha1));
+ interp_set_entry(table, ITREE_ABBREV,
+ find_unique_abbrev(commit->tree->object.sha1,
+ DEFAULT_ABBREV));
+ for (i = 0, p = commit->parents;
+ p && i < sizeof(parents) - 1;
+ p = p->next)
+ i += snprintf(parents + i, sizeof(parents) - i - 1, "%s ",
+ sha1_to_hex(p->item->object.sha1));
+ interp_set_entry(table, IPARENTS, parents);
+ for (i = 0, p = commit->parents;
+ p && i < sizeof(parents) - 1;
+ p = p->next)
+ i += snprintf(parents + i, sizeof(parents) - i - 1, "%s ",
+ find_unique_abbrev(p->item->object.sha1,
+ DEFAULT_ABBREV));
+ interp_set_entry(table, IPARENTS_ABBREV, parents);
+
+ for (i = 0, state = HEADER; msg[i] && state < BODY; i++) {
+ int eol;
+ for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
+ ; /* do nothing */
+
+ if (state == SUBJECT) {
+ table[ISUBJECT].value = xstrndup(msg + i, eol - i);
+ i = eol;
+ }
+ if (i == eol) {
+ state++;
+ /* strip empty lines */
+ while (msg[eol + 1] == '\n')
+ eol++;
+ } else if (!prefixcmp(msg + i, "author "))
+ fill_person(table + IAUTHOR_NAME,
+ msg + i + 7, eol - i - 7);
+ else if (!prefixcmp(msg + i, "committer "))
+ fill_person(table + ICOMMITTER_NAME,
+ msg + i + 10, eol - i - 10);
+ else if (!prefixcmp(msg + i, "encoding "))
+ table[IENCODING].value = xstrndup(msg + i, eol - i);
+ i = eol;
+ }
+ if (msg[i])
+ table[IBODY].value = xstrdup(msg + i);
+ for (i = 0; i < ARRAY_SIZE(table); i++)
+ if (!table[i].value)
+ interp_set_entry(table, i, "<unknown>");
+
+ interpolate(buf, space, user_format, table, ARRAY_SIZE(table));
+ interp_clear_table(table, ARRAY_SIZE(table));
+
+ return strlen(buf);
+}
+
unsigned long pretty_print_commit(enum cmit_fmt fmt,
const struct commit *commit,
unsigned long len,
@@ -727,6 +919,9 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
char *reencoded;
char *encoding;
+ if (fmt == CMIT_FMT_USERFORMAT)
+ return format_commit_message(commit, msg, buf, space);
+
encoding = (git_log_output_encoding
? git_log_output_encoding
: git_commit_encoding);
diff --git a/commit.h b/commit.h
index c737444..83507a0 100644
--- a/commit.h
+++ b/commit.h
@@ -47,6 +47,7 @@ enum cmit_fmt {
CMIT_FMT_FULLER,
CMIT_FMT_ONELINE,
CMIT_FMT_EMAIL,
+ CMIT_FMT_USERFORMAT,
CMIT_FMT_UNSPECIFIED,
};
diff --git a/log-tree.c b/log-tree.c
index ac86194..6ce239d 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -211,7 +211,7 @@ void show_log(struct rev_info *opt, const char *sep)
sha1, sha1);
opt->diffopt.stat_sep = buffer;
}
- } else {
+ } else if (opt->commit_format != CMIT_FMT_USERFORMAT) {
fputs(diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),
stdout);
if (opt->commit_format != CMIT_FMT_ONELINE)
--
1.5.0.1.620.gac8f
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 0:35 ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
@ 2007-02-23 1:03 ` Han-Wen Nienhuys
2007-02-23 1:07 ` Johannes Schindelin
2007-02-23 6:21 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2007-02-23 1:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
Johannes Schindelin escreveu:
> With this patch,
>
> $ git show -s \
> --pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
>
> shows something like
>
> Ze komit 04c5c88 woss
> dunn buy ze great Junio C Hamano
>
> The supported placeholders are:
nitpick:
\n
for newline would be nice. Similar for backslash, formfeed, alarm, etc.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 1:03 ` Han-Wen Nienhuys
@ 2007-02-23 1:07 ` Johannes Schindelin
2007-02-23 19:53 ` Robin Rosenberg
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 1:07 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git, junkio
Hi,
On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:
> nitpick:
>
> \n
>
> for newline would be nice. Similar for backslash, formfeed, alarm, etc.
Yes, I thought about that. But it would change behaviour (even if I don't
think it would do serious damage; the only user of interpolate.[ch] I saw
is git-daemon, and that does not need \n, I guess).
Besides, "%n" is
- more consistent,
- date(1) does it the same way, and
- you can put BS, FF, AL, etc. into the format string before passing
it as an option to git; git does not have to help you there.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 1:07 ` Johannes Schindelin
@ 2007-02-23 19:53 ` Robin Rosenberg
2007-02-24 1:25 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Robin Rosenberg @ 2007-02-23 19:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git, junkio
fredag 23 februari 2007 02:07 skrev Johannes Schindelin:
> Hi,
>
> On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:
>
> > nitpick:
> >
> > \n
> >
> > for newline would be nice. Similar for backslash, formfeed, alarm, etc.
>
> Yes, I thought about that. But it would change behaviour (even if I don't
> think it would do serious damage; the only user of interpolate.[ch] I saw
> is git-daemon, and that does not need \n, I guess).
Other tools that come to mind, rpm and clearcase use \n vfor newline in the
format argument, which is good because I can guess that even without looking
at the documentation. %n I'd guess would be for a number of some kind, e..g.
the ordinal number of the commit listed (in subset and order of the listed commits)
> Besides, "%n" is
>
> - more consistent,
with...?
> - date(1) does it the same way, and
Ok, I learnt something. Never fi
> - you can put BS, FF, AL, etc. into the format string before passing
> it as an option to git; git does not have to help you there.
They are hard to type in shells and even harder in gui's.
-- robin
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 19:53 ` Robin Rosenberg
@ 2007-02-24 1:25 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-24 1:25 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Han-Wen Nienhuys, git, junkio
Hi,
On Fri, 23 Feb 2007, Robin Rosenberg wrote:
> fredag 23 februari 2007 02:07 skrev Johannes Schindelin:
> >
> > On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:
> >
> > > nitpick:
> > >
> > > \n
> > >
> > > for newline would be nice. Similar for backslash, formfeed, alarm,
> > > etc.
> >
> > Yes, I thought about that. But it would change behaviour (even if I
> > don't think it would do serious damage; the only user of
> > interpolate.[ch] I saw is git-daemon, and that does not need \n, I
> > guess).
>
> Other tools that come to mind, rpm and clearcase use \n vfor newline in
> the format argument, which is good because I can guess that even without
> looking at the documentation. %n I'd guess would be for a number of some
> kind, e..g. the ordinal number of the commit listed (in subset and order
> of the listed commits)
Okay. Patch?
> > Besides, "%n" is
> >
> > - more consistent,
>
> with...?
... itself? Why should not _one_ escape character be enough?
> > - you can put BS, FF, AL, etc. into the format string before passing
> > it as an option to git; git does not have to help you there.
>
> They are hard to type in shells and even harder in gui's.
You would not do that all that often, but rather write a script. Even the
config format allows for inclusion of special characters, so aliases
should be fine.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 0:35 ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
2007-02-23 1:03 ` Han-Wen Nienhuys
@ 2007-02-23 6:21 ` Junio C Hamano
2007-02-23 11:48 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23 6:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git, junkio
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this patch,
>
> $ git show -s \
> --pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
>
> shows something like
>
> Ze komit 04c5c88 woss
> dunn buy ze great Junio C Hamano
Does it say "This commit is by a fool whose name is blah"?
> The supported placeholders are:
>
> '%H': commit hash
>...
> '%b': body
Hmmm. Would we want to make them somehow interoperable with
git-for-each-ref format atoms?
Also, it _might_ be worthwhile to do something like "%+4b"
which means "indent each line of this field with 4 spaces", for
a multi-line field like "%b".
> '%Cred': switch color to red
> '%Cgreen': switch color to green
> '%Cblue': switch color to blue
> '%Creset': reset color
Hmmm. I strongly suspect that we would want to reuse code to
grok colors and attributes in color.c.
> > --format 'committer %c\nauthor %a\n'
> >
> > this catches all combinations, and is easier for scripting.
I do not have strong preference between "\n" and "%n".
> So, I overcame my laziness after 91 days...
Thanks.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 6:21 ` Junio C Hamano
@ 2007-02-23 11:48 ` Johannes Schindelin
2007-02-23 18:30 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git
Hi,
On Thu, 22 Feb 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > With this patch,
> >
> > $ git show -s \
> > --pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
> >
> > shows something like
> >
> > Ze komit 04c5c88 woss
> > dunn buy ze great Junio C Hamano
>
> Does it say "This commit is by a fool whose name is blah"?
Vy, it iss korrekt Churmen Inklish [Translation: Why, it is correct
German "English"]... ;-)
> > The supported placeholders are:
> >
> > '%H': commit hash
> >...
> > '%b': body
>
> Hmmm. Would we want to make them somehow interoperable with
> git-for-each-ref format atoms?
But those placeholders are so long! Not even GNU date supports such long
placeholders... And I could not reuse interpolate.[ch] as is for that.
> Also, it _might_ be worthwhile to do something like "%+4b" which means
> "indent each line of this field with 4 spaces", for a multi-line field
> like "%b".
Same goes here: interpolate.[ch] does not (yet) allow for that.
> > '%Cred': switch color to red
> > '%Cgreen': switch color to green
> > '%Cblue': switch color to blue
> > '%Creset': reset color
>
> Hmmm. I strongly suspect that we would want to reuse code to grok
> colors and attributes in color.c.
And again...
> > > --format 'committer %c\nauthor %a\n'
> > >
> > > this catches all combinations, and is easier for scripting.
>
> I do not have strong preference between "\n" and "%n".
This would be easy, methink, to teach to interpolate().
Maybe I can overcome my laziness, and extend interpolate() so that it can
actually call callbacks with callback data...
Alternatively, I could imitate for-each-ref, and roll my own
interpolate()? :-)
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 11:48 ` Johannes Schindelin
@ 2007-02-23 18:30 ` Junio C Hamano
2007-02-23 18:38 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2007-02-23 18:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > The supported placeholders are:
>> >
>> > '%H': commit hash
>> >...
>> > '%b': body
>>
>> Hmmm. Would we want to make them somehow interoperable with
>> git-for-each-ref format atoms?
>
> But those placeholders are so long! Not even GNU date supports such long
> placeholders... And I could not reuse interpolate.[ch] as is for that.
What I was hinting at was to fix (or extend) for-each-ref to
accept these short-and-sweet placeholders.
>> Also, it _might_ be worthwhile to do something like "%+4b" which means
>> "indent each line of this field with 4 spaces", for a multi-line field
>> like "%b".
>
> Same goes here: interpolate.[ch] does not (yet) allow for that.
Nah, if you feel it is too much work, I trust your judgement (I
do not recall details of how interpolate.c does its thing). I
do not think it's worth it.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH for "next"] pretty-formats: add 'format:<string>'
2007-02-23 18:30 ` Junio C Hamano
@ 2007-02-23 18:38 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2007-02-23 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, git
Hi,
On Fri, 23 Feb 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > The supported placeholders are:
> >> >
> >> > '%H': commit hash
> >> >...
> >> > '%b': body
> >>
> >> Hmmm. Would we want to make them somehow interoperable with
> >> git-for-each-ref format atoms?
> >
> > But those placeholders are so long! Not even GNU date supports such
> > long placeholders... And I could not reuse interpolate.[ch] as is for
> > that.
>
> What I was hinting at was to fix (or extend) for-each-ref to accept
> these short-and-sweet placeholders.
Ah, the other way round...
> >> Also, it _might_ be worthwhile to do something like "%+4b" which
> >> means "indent each line of this field with 4 spaces", for a
> >> multi-line field like "%b".
> >
> > Same goes here: interpolate.[ch] does not (yet) allow for that.
>
> Nah, if you feel it is too much work, I trust your judgement (I
> do not recall details of how interpolate.c does its thing). I
> do not think it's worth it.
Sure, it _would_ be nice to let interpolate call back, instead of having
to fill a table with static strings (xstrdup()ing them, no less).
However, I want to go play Snooker tonight, so this is up-for-grabs.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 10:45 ` Han-Wen Nienhuys
2006-11-16 11:11 ` Junio C Hamano
@ 2006-11-16 16:23 ` Linus Torvalds
2006-11-16 16:42 ` Han-Wen Nienhuys
1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 16:23 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> This is not about CVS or SVN, so don't put them up as a strawman.
> If you want to argue that my brain is warped, use other distributed VCs as an
> example.
Your example has nothing at all to do with "pull" vs "fetch", though.
Your example is about something totally _different_, namely that under
git, "git init-db" is _only_ for creating a _new_ project.
> The following
>
> mkdir x y
> cd x
> hg init
> echo hoi > bla
> hg add
> hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'
> cd ../y
> hg init
> hg pull ../x
>
> pretty much works the same in Darcs, bzr and mercurial.
>
> With GIT, this is what happens
>
> [hanwen@haring y]$ git pull ../x
Bzzt. This is where you went wrong, and you blamed "pull".
The way you do this in git is to NOT do "git init". Instead, you replace
all the
mkdir y
cd ../y
hg init
hg pull ../x
with a simple
git clone x y
and YOU ARE DONE.
Now, we could certainly _make_ "git pull" work on an empty git project,
but that has _nothing_ to do with what people have been talking about.
In fact, the fact that "git fetch" kind of works is not exactly accidental
(because "git fetch" _is_ meant to add new local branches too), but all
the problems you have with it are due to the SAME issue. You started
without any branch at all, because you started with an empty git repo, and
you're simply not _supposed_ to do that.
So current rule (and this is not new, it's always been true): the ONLY
time you use "git init-db" is when you are going to start a totally new
project. Never _ever_ otherwise. If you want to track another project, use
"git clone".
> This might not be typical GIT use, but it does show the typical GIT user
> experience, at least mine.
It's not that it isn't typical, it's that you are using the wrong model.
Maybe it's not well documented, I can easily give you that, but ALL your
problems come from that fundamental starting point: you shouldn't have
used "git init-db" in the first place.
Somebody want to document it?
Alternatively, we certainly _could_ make "git pull" just accept an empty
git repo, and make it basically create the current branch.
(And we probably should improve the error messahe)
> I don't want ANYTHING to really change, I just want a sane interface to it.
The sane interface _exists_. It's called "git clone".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:23 ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 16:42 ` Han-Wen Nienhuys
2006-11-16 17:17 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 16:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
> So current rule (and this is not new, it's always been true): the ONLY
> time you use "git init-db" is when you are going to start a totally new
> project. Never _ever_ otherwise. If you want to track another project, use
> "git clone".
Actually, only a 2 weeks ago, you suggested that I share the website
and main source code for my project in a single repository for reasons
of organization.
In this setup I find it logical to do
git init-db
git pull ..url.. website/master
to wind up with just the 5mb website, instead of the complete 70mb
of packed source code with all of its branches and tags.
> It's not that it isn't typical, it's that you are using the wrong model.
> Maybe it's not well documented, I can easily give you that, but ALL your
> problems come from that fundamental starting point: you shouldn't have
> used "git init-db" in the first place.
>
> Somebody want to document it?
>
> Alternatively, we certainly _could_ make "git pull" just accept an empty
> git repo, and make it basically create the current branch.
Yes, I would like that.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 16:42 ` Han-Wen Nienhuys
@ 2006-11-16 17:17 ` Linus Torvalds
2006-11-16 17:40 ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:17 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> Actually, only a 2 weeks ago, you suggested that I share the website
> and main source code for my project in a single repository for reasons
> of organization.
>
> In this setup I find it logical to do
>
> git init-db
> git pull ..url.. website/master
I don't disagree per se. It should be easy to support, it's just that it's
not traditionally been something we've ever done.
So the way you'd normally set up a single repo that contains multiple
other existing repositories is to basically start with one ("git clone")
and then add the other branches and "git fetch" them.
So again, instead of "git init-db" + "git pull", you'd just use "git
clone" instead.
Note that there _is_ another difference between "git pull" and
"fetch+merge". The difference being that "git pull" implicitly does the
checkout for you (I say "implicitly", because that's the way the git
merge conceptually works: we always merge in the working tree. That's not
the only way it _could_ be done, though - for trivial merges, we could do
them without any working tree at all, but we don't suppotr that).
And that "git pull" semantic actually means that if you want a _bare_
repository, I think "git --bare init-db" + "git --bare fetch" actually
does exactly the right thing right now too. But "git pull" would not be
the right thing to use.
Btw, another normal way to generate a central "multi-headed repo" for is
to not use "pull" or "fetch" or "clone" at ALL, but I would likely do
something like
mkdir central-repo
cd central-repo
git --bare init-db
and that's it. You now have a central repository, and you _never_ touch it
again in the central place except to repack it and do other "maintenance"
(eg pruning, fsck, whatever).
Instead, from the _outside_, you'd probably just do
git push central-repo mybranch:refs/heads/central-branch-name
(actually, you'd probably set up that branch-name translation of
"mybranch:refs/heads/central-branch-name" in your remote description, but
I'm writing it out in full as an example).
So there are many ways to do it. It just happens that "git init-db"
followed by "git pull" is not one of them ;)
(And the real reason for that is simple: "git pull" simply wants to have
something to _start_ with. It's not hugely fundamental, it's just how it
was written).
^ permalink raw reply [flat|nested] 601+ messages in thread
* multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 17:17 ` Linus Torvalds
@ 2006-11-16 17:40 ` Han-Wen Nienhuys
2006-11-16 18:21 ` Linus Torvalds
2006-11-16 17:57 ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 18:13 ` Carl Worth
2 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 17:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
>
> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>> Actually, only a 2 weeks ago, you suggested that I share the website
>> and main source code for my project in a single repository for reasons
>> of organization.
>>
>> In this setup I find it logical to do
>>
>> git init-db
>> git pull ..url.. website/master
>
> I don't disagree per se. It should be easy to support, it's just that it's
> not traditionally been something we've ever done.
>
> So the way you'd normally set up a single repo that contains multiple
> other existing repositories is to basically start with one ("git clone")
You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
remote one. The example I gave was about locally creating a single
project repo from a remote multiproject repo.
On a tangent: why is there no reverse-clone? I have no shell access
to the machine, so when I created the remote repo, I had to push, and
ended up putting 1.2 Gb data on the server.
<looks at manpage>
is this send-pack? From UI perspective it would be nice if this could
also be done with clone,
git clone . ssh+git://....
>And that "git pull" semantic actually means that if you want a _bare_
>repository, I think "git --bare init-db" + "git --bare fetch" actually
yes, this works. Two remarks:
* it needs
website/master:master
otherwise you still don't have a branch.
* why are objects downloaded twice? If I do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
it downloads stuff, but I don't get a branch. If I then do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
it downloads the same stuff again.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 17:40 ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
@ 2006-11-16 18:21 ` Linus Torvalds
2006-11-16 18:33 ` multi-project repos Junio C Hamano
` (3 more replies)
0 siblings, 4 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 18:21 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
>
> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
> remote one. The example I gave was about locally creating a single
> project repo from a remote multiproject repo.
Ahh.
Ok, try the patch I just sent out, and see if it works for you. It
_should_ allow you to do exactly that
mkdir new-repo
cd new-repo
git init-db
git pull <remote> <onehead>
and now your "master" branch should be initialized to "onehead".
Oh, except I just realized that I forgot to do a "git checkout" in my
patch, so you'd need to add that (or do it by hand, but you really
shouldn't need to, since the checkout is implied by the "pull").
The downside with this is that it does NOT populate your "remotes"
information (like "git clone" would have done), so either we'd need to
teach "git pull" to do that too, or you just have to do it by hand (so
that you then can do the shorthand "git pull" to update in the future).
> On a tangent: why is there no reverse-clone? I have no shell access
> to the machine, so when I created the remote repo, I had to push, and
> ended up putting 1.2 Gb data on the server.
Yeah, you're supposed to "init-db" and "push". Right now, that tends to
unpack everything (which is bad), although that is hopefully getting fixed
(ie the receiving end shouldn't unpack any more if it is recent. Junio?)
> <looks at manpage>
>
> is this send-pack?
"git push" uses send-pack internally, you shouldn't ever need to use it
yourself.
> From UI perspective it would be nice if this could also be done with clone,
>
> git clone . ssh+git://....
The creation of a new archive tends to need special rights (with _real_
ssh access and a shell you could do it, but "ssh+git" really means "git
protocol over a connection that was opened with ssh, but doesn't
necessarily have a real shell at the other end").
So for most protocols, you simply cannot (and shouldn't) do it. Think
about services like the one that Pasky has set up, that allow you to set
up a new git repo - the setup phase really _has_ to be separate (because
you need to set up your keys etc).
So I think the above syntax is actually not a good one, because it cannot
work in the general case. It's much better to get used to setting up a
repo first, and then pushing into it, and just accepting that it's a
two-phase thing.
Also, from a bandwidth standpoint, you can often (although obviously not
always) make the setup start with something that is _closer_ to what you
want to do. So, for example, you'd often do something like:
(a) ssh to central repository
(b) create the new repository by cloning it _locally_ at the central
place from some other repository that is related
(c) then, from your local (non-central) repository, do a "git push --force"
to force your changes (which now only needs the _incremental_ thing).
An example of this is again the "forking" thing that he repos at at
http://git.or.cz/ already supports.
> >And that "git pull" semantic actually means that if you want a _bare_
> >repository, I think "git --bare init-db" + "git --bare fetch" actually
>
> yes, this works. Two remarks:
>
> * it needs
>
> website/master:master
>
> otherwise you still don't have a branch.
Right. In fact, you should probably do
website/master:refs/heads/master
just to make it really explicit.
> * why are objects downloaded twice? If I do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
>
> it downloads stuff, but I don't get a branch.
A "fetch" by default won't actually generate a local branch unless you
told it to. It just squirrels the end result into the magic FETCH_HEAD
name, so that you can do
# do the fetch
git fetch git://git.sv.gnu.org/lilypond.git web/master
# look at changes
gitk ..FETCH_HEAD
# If you're happy with them, merge them in
git merge "merge new code" HEAD FETCH_HEAD
and you never actually created a real local branch at all.
If you want "git fetch" to fetch _into_ a branch, you need to tell it so,
by using the full "src:dest" format. Otherwise it doesn't know what branch
to fetch it into.
(And, of course, you can define that branch relationship in your remote
configuration, so you don't actually have to say it explicitly every time)
> If I then do
>
> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>
> it downloads the same stuff again.
Right. So you can either
(a) do it that way to begin with (because you now told it to put the
results in "master", so you never needed to do the second fetch in
the first place)
or
(b) after you did the first fetch (into FETCH_HEAD), you could also have
just decided to do
git update-ref HEAD FETCH_HEAD ""
(where that "" at the end is really not technically necessary, but it
tells "update-ref" that you _only_ want to do this if the old HEAD
was empty/undefined. Without it, "git update-ref" will just
overwrite HEAD without caring what it contained before, so it can be
a dangerous operation!)
See?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-16 18:21 ` Linus Torvalds
@ 2006-11-16 18:33 ` Junio C Hamano
2006-11-16 19:01 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
` (2 subsequent siblings)
3 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 18:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Han-Wen Nienhuys
Linus Torvalds <torvalds@osdl.org> writes:
> Yeah, you're supposed to "init-db" and "push". Right now, that tends to
> unpack everything (which is bad), although that is hopefully getting fixed
> (ie the receiving end shouldn't unpack any more if it is recent. Junio?)
Correct.
> See?
>
> Linus
Saw.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 18:21 ` Linus Torvalds
2006-11-16 18:33 ` multi-project repos Junio C Hamano
@ 2006-11-16 19:01 ` Linus Torvalds
2006-11-17 16:26 ` Shawn Pearce
2006-11-16 22:21 ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
2006-11-16 23:32 ` Han-Wen Nienhuys
3 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 19:01 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> A "fetch" by default won't actually generate a local branch unless you
> told it to. It just squirrels the end result into the magic FETCH_HEAD
> name [...]
Btw, the magic heads are probably not all that well documented. They do
come up in the man-pages, but I don't think there is any central place
talking about them. We have:
- "HEAD" itself, which is obviously the default pointer for a lot of
operations, and that specifies the current branch (ie it should
currently always be a symref, although we've talked about relaxing
that)
- "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
(or some other operations, like "git rebase" and "git reset": think of
it as a "original head before we did some uncontrolled operation
where we otherwise can't use HEAD^ or similar")
I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
pull I've done. This is important exactly because ORIG_HEAD is _not_
the same as the first parent of a merge, since a merge could have been
just a fast-forward.
- "FETCH_HEAD" as mentioned. Normally you'd only use this in scripting, I
suspect, but it's potentially useful if you prefer to do a fetch first
and then check out it (perhaps cherry-picking stuff instead of merging,
for example).
So you could do (for example)
git fetch some-other-repo branch
gitk ..FETCH_HEAD
git cherry-pick <some-particular-commit-you-picked>
- "MERGE_HEAD" is kind of the opposite of "ORIG_HEAD" when you're in
the middle of a merge: it's the "other" branch that you're merging.
It's mainly useful for merge resolution, ie
git log -p HEAD...MERGE_HEAD -- some/file/with/conflicts
is a great way to see what happened along both branches (note the
_triple_ dot: it's a symmetric difference), to see _why_ the confict
happened.
Most of the above are used implicitly in various cases, not just HEAD. The
"--merge" flag to git-rev-list (and thus git log and friends) is just
shorthand for the above "HEAD...MERGE_HEAD" behaviour (with the addition
of also limiting the result to just conflicting files), so
git log -p --merge
is basically exactly the same as the above (except for _all_ files that
have conflicts in them rather than just one hand-specified one).
Anyway, maybe somebody didn't know about these, and finds them useful.
Normally, the only one you would _really_ use is "ORIG_HEAD" (which is
described in several of the tutorials and examples, so people hopefully
already know about it). Most of the others tend to mostly be used
implicitly, not by explicitly naming them - although you _can_.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 19:01 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-17 16:26 ` Shawn Pearce
2006-11-17 16:45 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 16:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Linus Torvalds <torvalds@osdl.org> wrote:
> - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
> (or some other operations, like "git rebase" and "git reset": think of
> it as a "original head before we did some uncontrolled operation
> where we otherwise can't use HEAD^ or similar")
>
> I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
> when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
> pull I've done. This is important exactly because ORIG_HEAD is _not_
> the same as the first parent of a merge, since a merge could have been
> just a fast-forward.
Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:
gitk HEAD@{1}..
as recent Git understands that to mean the value that HEAD just had,
which is also what is in ORIG_HEAD. Except that unlike ORIG_HEAD
it can also show even older values (e.g. HEAD@{3}, 3 ops back)
and it works very, very well on tracking branches. "What did I
just fetch in next?" `git log next@{1}..next`
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 16:26 ` Shawn Pearce
@ 2006-11-17 16:45 ` Linus Torvalds
2006-11-17 16:51 ` Carl Worth
2006-11-17 17:08 ` Shawn Pearce
2006-11-17 16:46 ` Carl Worth
2006-11-17 17:39 ` Junio C Hamano
2 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17 16:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1391 bytes --]
On Fri, 17 Nov 2006, Shawn Pearce wrote:
>
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
"three pretty complicated characters longer" and "off the normal path
where you hold your fingers on the keyboard ;)
And that's not even mentioning that '{'/'}' is a magic sequence for
filename expansion to the shell, so every time I see that, I have to think
about it (and it turns out that because there is no comma in between
there, it's ok. Otherwise you would need to quote it or escape them...)
So the reflog syntax is fine, but it's definitely not a "simple" syntax.
I'd only use it for things where I want something that ORIG_HEAD won't
give me ("ORIG_HEAD" you can type by just holding the shift key down all
the time, and letting your fingers dance over the keyboard, both on a US
and a Finnish keyboard).
And yes, I actually use a Finnish keyboard, still. Don't ask me why. I
don't actually need the åäö characters often enough for it to matter, and
I have used US keyboards elsewhere enough that I can switch between the
two without thinking, but I still ended up having my sister ship me a
keyboard from Finland when I wanted to upgrade..
Linus
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 16:45 ` Linus Torvalds
@ 2006-11-17 16:51 ` Carl Worth
2006-11-17 17:08 ` Shawn Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Han-Wen Nienhuys, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Fri, 17 Nov 2006 08:45:39 -0800 (PST), Linus Torvalds wrote:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)
It's not even all that convenient on a U.S. keyboard. My pinky suffers
a bit having to pop on and off of shift for the '{', '1', '}'. Then
again, I don't like having to hold shift down for all of ORIG_HEAD
either, (but it's definitely easier in comparison).
But since reflog does everything ORIG_HEAD does and more, shall we
just clean up the syntax somehow? Ideas anyone? And then fix the
documentation to explain that?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 16:45 ` Linus Torvalds
2006-11-17 16:51 ` Carl Worth
@ 2006-11-17 17:08 ` Shawn Pearce
1 sibling, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 17:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Linus Torvalds <torvalds@osdl.org> wrote:
> On Fri, 17 Nov 2006, Shawn Pearce wrote:
> >
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)
I forgot that you use a finnish keyboard. :-)
I agree with you; its not easier to type, for you. Me, I'm a dumb
American who uses a Kinesis keyboard, therefore my left foot is
my shift key and its in sync with my fingers. I have no extra
pinky load for either syntax. And since the reflog syntax works
in a lot more contexts (e.g. after a fetch into a tracking branch)
I have just forgotten about ORIG_HEAD entirely. Oh sure, I know
its there, but its not something I think about using...
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 16:26 ` Shawn Pearce
2006-11-17 16:45 ` Linus Torvalds
@ 2006-11-17 16:46 ` Carl Worth
2006-11-17 17:15 ` Shawn Pearce
2006-11-17 17:39 ` Junio C Hamano
2 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-17 16:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Fri, 17 Nov 2006 11:26:05 -0500, Shawn Pearce wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
...
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.
I would very much like to see reflog getting first-class citizen
support in git:
1. Be on by default
2. Get documented in all the right places, (much better than adding
documentation for ORIG_HEAD in my opinion)
3. Tighter integration with branch manipulations. Do we already delete
reflog when deleting a branch? We don't have a branch rename
operation, but if we get one, renaming the reflog should go
hand-in-hand, etc.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 16:46 ` Carl Worth
@ 2006-11-17 17:15 ` Shawn Pearce
2006-11-17 17:50 ` Marko Macek
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-17 17:15 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
Carl Worth <cworth@cworth.org> wrote:
> Yes, this was my exact thought when reading what Linus
> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
> compared to what reflog provides.
>
> I would very much like to see reflog getting first-class citizen
> support in git:
>
> 1. Be on by default
I have:
git repo-config --global core.logAllRefUpdates true
especially since Junio fixed it to only create logs for heads and
not tags. That way its on by default for me. But I think it should
be on by default in the next version of Git.
> 2. Get documented in all the right places, (much better than adding
> documentation for ORIG_HEAD in my opinion)
Agreed. I'm not likely to do it anytime soon however, so I'm hoping
someone else will do it... :-)
> 3. Tighter integration with branch manipulations. Do we already delete
> reflog when deleting a branch? We don't have a branch rename
> operation, but if we get one, renaming the reflog should go
> hand-in-hand, etc.
Yes, we delete the log when we delete the branch, and we prune
back the empty directories too just like we do on the branch side,
so that new branches can be correctly created.
There was a recent discussion about that from Junio if I recall.
Several people that I work with have asked that branch rename
support be added to Git, and that if you rename the branch the
reflog follows. Because in their mind they are simply changing
the name of the branch, any old history of that branch should
stick around.
I tried to think of an option to "git branch" to do the rename but
kept thinking that:
git rename-branch old new
is the better syntax... even though that's command number 133
or something like that...
We should stick a "null" event into the reflog during a branch
rename. Make both the old and new SHA1 the current SHA1 but drop
a message in saying "renamed branch old -> new" (for example).
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 17:15 ` Shawn Pearce
@ 2006-11-17 17:50 ` Marko Macek
2006-11-17 20:24 ` multi-project repos Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Marko Macek @ 2006-11-17 17:50 UTC (permalink / raw)
To: git; +Cc: junkio
Shawn Pearce wrote:
> Carl Worth <cworth@cworth.org> wrote:
>> Yes, this was my exact thought when reading what Linus
>> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
>> compared to what reflog provides.
>>
>> I would very much like to see reflog getting first-class citizen
>> support in git:
>>
>> 1. Be on by default
I agree.
> I have:
>
> git repo-config --global core.logAllRefUpdates true
>
> especially since Junio fixed it to only create logs for heads and
> not tags. That way its on by default for me. But I think it should
> be on by default in the next version of Git.
Why is it not useful for tags for having logs?
I also have a question:
Does git-fsck-objects/prune check the ref logs?
Mark
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-17 17:50 ` Marko Macek
@ 2006-11-17 20:24 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 20:24 UTC (permalink / raw)
To: Marko Macek; +Cc: git
Marko Macek <marko.macek@gmx.net> writes:
> Shawn Pearce wrote:
>...
>> I have:
>>
>> git repo-config --global core.logAllRefUpdates true
>>
>> especially since Junio fixed it to only create logs for heads and
>> not tags. That way its on by default for me. But I think it should
>> be on by default in the next version of Git.
>
> Why is it not useful for tags for having logs?
When I make a tag that says "this is the v1.2.0 release", it is
expected it won't change in the future, ever. I _can_ make
mistake and tag a wrong commit under v1.2.0 name, in which case
I may have to replace it with another corrected tag, but
recoding that mistake does not really add value. So most of the
time ref-log for a tag would contain only one entry per file, its
creation, but that creation time is already recorded in the tag
object itself anyway.
At times, it may be useful to have some floating tag that point
at the "latest", or "today's", but that use is a minority. For
these minority cases, you can manually create an empty file
under .git/logs/ directory to record their updates.
The configuration mechanism only kicks in when there is no such
existing file to prime the process, and not creating ref-log for
tags by default is the sensible thing to do.
> I also have a question:
>
> Does git-fsck-objects/prune check the ref logs?
They deliberately ignore ref-log for the same reason lost-found
does not drop found refs under .git/refs hierarchy.
This only matters if you somehow rewind an existing branch in
order to lose part of its history, using "reset --hard HEAD~n"
or "rebase". If the updates to your branch tips always build on
top of the previous (either by commiting on top of the current,
merging on top of the current, or fast-forwarding), and if you
never rewind the branch, the commits recorded in the ref-log for
the branch are always ancestors of the tip of the branch, so
checking ref-log does not give you anything other than slowing
the operation down.
However, if you rewind the tip of a branch, the story changes.
Until the next "prune", objects reachable from the ref-log of
the branch but not reachable from the tip of the branch are
still available in your object store and in a pinch you can
recover them, but after a "prune" they will be lost forever if
they do not have any other references. So it might seem that
they should be protected from pruning.
But if you did so, you can never remove cruft from your object
store once you make a mistake. You can clean up your history by
a reset and/or a rebase, and cleaning up to _lose_ part of the
history was the reason you rewound the branch in the first
place.
In other words, running 'prune' is a conscious act of saying "I
know I am not in the middle of something; I thought over what
I've done recently, salvaged necessary bits from what I
discarded earlier, and there is nothing that need to be salvaged
later anymore -- I have refs to what I need. Now go clean up
the cruft from my object store".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-17 16:26 ` Shawn Pearce
2006-11-17 16:45 ` Linus Torvalds
2006-11-17 16:46 ` Carl Worth
@ 2006-11-17 17:39 ` Junio C Hamano
2006-11-18 6:02 ` Shawn Pearce
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 17:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
Shawn Pearce <spearce@spearce.org> writes:
> Linus Torvalds <torvalds@osdl.org> wrote:
>> - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
>> (or some other operations, like "git rebase" and "git reset": think of
>> it as a "original head before we did some uncontrolled operation
>> where we otherwise can't use HEAD^ or similar")
>>
>> I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
>> when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
>> pull I've done. This is important exactly because ORIG_HEAD is _not_
>> the same as the first parent of a merge, since a merge could have been
>> just a fast-forward.
>
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Are you sure about this? I've seen "next@{1}" to look at
history of the named branch, but never history of "HEAD".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-17 17:39 ` Junio C Hamano
@ 2006-11-18 6:02 ` Shawn Pearce
2006-11-18 7:31 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-18 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Are you sure about this? I've seen "next@{1}" to look at
> history of the named branch, but never history of "HEAD".
Yes. :-)
If the ref name is a symref then we resolve the symref all the
way down to the real ref before we open and walk the reflog.
Therefore this works.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-18 6:02 ` Shawn Pearce
@ 2006-11-18 7:31 ` Junio C Hamano
2006-11-18 7:45 ` Shawn Pearce
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-18 7:31 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>> > Although if you have reflog enabled on your current branch there
>> > is a 1 character shorter syntax:
>> >
>> > gitk HEAD@{1}..
>>
>> Are you sure about this? I've seen "next@{1}" to look at
>> history of the named branch, but never history of "HEAD".
>
> Yes. :-)
>
> If the ref name is a symref then we resolve the symref all the
> way down to the real ref before we open and walk the reflog.
> Therefore this works.
True, except if you did:
$ git pull
$ git checkout otherbranch
$ git show HEAD@{1}
My real point was that I was wondering if it also makes sense
for ref-log to record switching branches for the symref itself.
But after sending that message I thought about it a bit more and
concluded that it is not an interesting information. It is more
code that affects unrelated places even if we were to implement
it and without real gain, so let's not log symref itself and
keep the current implementation.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-18 7:31 ` Junio C Hamano
@ 2006-11-18 7:45 ` Shawn Pearce
0 siblings, 0 replies; 601+ messages in thread
From: Shawn Pearce @ 2006-11-18 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
Junio C Hamano <junkio@cox.net> wrote:
> True, except if you did:
>
> $ git pull
> $ git checkout otherbranch
> $ git show HEAD@{1}
>
> My real point was that I was wondering if it also makes sense
> for ref-log to record switching branches for the symref itself.
>
> But after sending that message I thought about it a bit more and
> concluded that it is not an interesting information. It is more
> code that affects unrelated places even if we were to implement
> it and without real gain, so let's not log symref itself and
> keep the current implementation.
I agree completely.
I have no interest in a history of what branches I've recently
been on. All I care about is the history of this branch. And I
consider HEAD to be nothing but a shortcut that always points to
the current branch... so its darn useful for that.
In retrospect CURR may have been a better name for the HEAD symref
but its far too late to even consider changing that, so lets not
go down that road. :-)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 18:21 ` Linus Torvalds
2006-11-16 18:33 ` multi-project repos Junio C Hamano
2006-11-16 19:01 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-16 22:21 ` Johannes Schindelin
2006-11-16 22:44 ` multi-project repos Junio C Hamano
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-16 23:32 ` Han-Wen Nienhuys
3 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 22:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
> >
> > * why are objects downloaded twice? If I do
> >
> > git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
> >
> > it downloads stuff, but I don't get a branch.
>
> A "fetch" by default won't actually generate a local branch unless you
> told it to.
This is actually a perfect example for
- a script that is porcelain as well as plumbing (you are supposed to use
it directly, or via pull), and for
- a terrible UI.
_If_ you use git-fetch directly you virtually always want to store the
result. I was tempted quite often to submit a patch which adds a command
line switch --no-warn, which is passed to git-fetch by git-pull, and
without which git-fetch complains if the branch-to-be-fetched is not
stored right away (and refuses to go along).
_Also_, git-pull not storing the fetched branches at least temporarily
often annoyed me: the pull did not work, and the SHA1 was so far away I
could not even scroll to it. The result: I had to pull (and fetch!) the
whole darned objects again. Again, I was tempted quite often to submit a
patch which makes git-pull fetch the branches into refs/fetch-temp/* and
only throw them away when the merge succeeded.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-16 22:21 ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
@ 2006-11-16 22:44 ` Junio C Hamano
2006-11-17 0:29 ` Johannes Schindelin
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 22:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> _If_ you use git-fetch directly you virtually always want to store the
> result. I was tempted quite often to submit a patch which adds a command
> line switch --no-warn, which is passed to git-fetch by git-pull, and
> without which git-fetch complains if the branch-to-be-fetched is not
> stored right away (and refuses to go along).
>
> _Also_, git-pull not storing the fetched branches at least temporarily
> often annoyed me: the pull did not work, and the SHA1 was so far away I
> could not even scroll to it. The result: I had to pull (and fetch!) the
> whole darned objects again. Again, I was tempted quite often to submit a
> patch which makes git-pull fetch the branches into refs/fetch-temp/* and
> only throw them away when the merge succeeded.
I think the earlier write-up by Linus on magic HEADs would help
documenting FETCH_HEAD better.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos
2006-11-16 22:44 ` multi-project repos Junio C Hamano
@ 2006-11-17 0:29 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Thu, 16 Nov 2006, Junio C Hamano wrote:
> I think the earlier write-up by Linus on magic HEADs would help
> documenting FETCH_HEAD better.
I am not sure that documenting FETCH_HEAD better would help. As Han-Wen
pointed out (and some colleagues of mine who would never subscribe to a
mailing list), people do not read the manual, but rather try to wrap their
heads around the inner workings from the interface. And FETCH_HEAD just
does not meet _any_ expectation a sane (read: untainted) user might have.
While I'm at it: the problem I pointed out with -pull may annoy just me.
But there is another problem with "git fetch": a common work flow is
tracking other peoples branches. And since git makes it so easy to
have multiple branches, chances are that you track more than one
branch per remote repository.
Now, an old gripe of mine was the lack of "git fetch --all". I wrote a
script for that (Linus would be proud of me!), which just does "git
ls-remote" and constructs a command line for "git fetch" from that.
But even if you agree with the common story that you should specify the
branches you want to track: it is hard!
If I were new to git, after reading some tutorials I would _expect_ "git
fetch" to be the tool to track branches. (I posted a patch to at least be
able to store the current "git fetch" command line under a nick IIRC). But
it does not.
(Of course, after reading several documentation, as a new user I would
eventually find that I should edit .git/remotes/<nick>, or even
edit/-repo-config the remotes information in the config, but I would fully
expect a new user to give up before reaching that stage.)
But maybe I got it all wrong and this is not the common expectation...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 22:21 ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
2006-11-16 22:44 ` multi-project repos Junio C Hamano
@ 2006-11-16 22:49 ` Linus Torvalds
2006-11-16 23:08 ` Linus Torvalds
` (2 more replies)
1 sibling, 3 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 22:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
On Thu, 16 Nov 2006, Johannes Schindelin wrote:
>
> - a terrible UI.
Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
> _Also_, git-pull not storing the fetched branches at least temporarily
> often annoyed me: the pull did not work, and the SHA1 was so far away I
> could not even scroll to it.
Again, why didn't you use FETCH_HEAD?
If the user doesn't give us a head to write to, we clearly MUST NOT write
to any long-term branch. That would be a _horrible_ mistake.
So all your complaints seem totally misplaced. The UI is both usable and
practical, and your complaint that git pull doesn't store the fetched
branches is just NOT TRUE.
And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT
overwrite any existing branches unless explicitly told to do so by the
user.
So I really don't see your point.
A lot of the complaints seem to not be about the interfaces, but about
people not _understanding_ and knowing what the interfaces do. If you were
confused about something (like not realizing that FETCH_HEAD is there and
very much usable), how about sending in a patch to make FETCH_HEAD use
clearer in whatever docs you looked at and didn't find it mentioned in.
Now, there is no question that some of the interfaces can get a bit
"interesting" to use. For example, if you really don't want to re-fetch
for some reason, FETCH_HEAD actually does contain enough information that
you should be able to just re-do a failed merge, for example, including
the message generation. But at that point it really _does_ get a bit
complicated, and you end up doing something like
git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
which should _work_, but I'm not going to claim that it's all that easy to
understand.
(That said, read that one-liner a few times, and suddenly it doesn't seem
_that_ complicated any more, now does it? You can probably even guess what
it's really going to do, even if you don't know git all that well. It's
not unreadable line noise, is it?)
Of course, if I had a merge that failed (the most common reason being that
I had some uncommitted patch in a file that wanted to be updated by the
merge), I'd never actually do the above one-liner. I'd just re-do the
pull. But if networking was _really_ slow, and I _really_ cared, maybe I'd
do the above.
(And no, I didn't actually test the above one-liner. Maybe it doesn't work
for some reason. Somebody should check, just for fun).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
@ 2006-11-16 23:08 ` Linus Torvalds
2006-11-16 23:36 ` Johannes Schindelin
2006-11-16 23:40 ` Han-Wen Nienhuys
2 siblings, 0 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
Btw, I'd like to claim that this is a _great_ user interface.
Yeah, it's different from other SCM's. I don't think you'd really want to
script a merge like this in CVS, especially not using standard UNIX
pipelines etc. But it's an example of how a lot of git operations - even
the "high level ones" are pretty scriptable, using very basic and very
simple standard UNIX shell scripting.
So even though I'd not actually _do_ the above one-liner, I think it's a
great example of how git really works, and how scriptable it can be,
without a lot of huge problems.
So considering that "FETCH_HEAD" works pretty much everywhere, and that
you can also use the totally non-scripting approach of doing "standard"
SCM things like
git diff ..FETCH_HEAD
or
gitk HEAD...FETCH_HEAD
to look at what got fetched (and in the latter case look at both the
current HEAD _and_ FETCH_HEAD, and what was in one but not the other), I
really think it's unfair to say that "git fetch" does not have a nice UI.
It's just that "git fetch" can be used two totally different ways:
- "git fetch" to get something temporary: use FETCH_HEAD, and do _not_
specify a destination branch
- "git fetch" as a way to update the branches you already have, by either
using explicit branch specifiers (which would be unusual, but works),
or by just having the branch relationships listed in your .git/remotes/
file or .git/config file.
both are actually very natural things to do.
What is probably _not_ that natural is to do the explicit branch
specifier, ie
git fetch somerepo remotebranch:localbranch
which obviously works, but you wouldn't want to actually do this very
often. Either you do something once (and use FETCH_HEAD, which is actually
nicer than a real branch in some respects: it also tells you were you
fetched _from_, and it can contain data on merging from _multiple_
branches), or you set up a "real translation" in your configuration files.
So I would say that the natural thing to do is:
- "git pull somerepo"
This will _also_ fetch all the branches you've said you want to track,
of course.
- "git fetch somerepo somebranch"
Look at FETCH_HEAD, and be happy
- "git fetch somerepo"
This is kind of strange, but it can be useful if you are basically just
mirroring another repo, and want to fetch all the branches you've said
you want to track, but don't actually want to check them out.
while the "complicated" scenario like the following is something you
should generally _avoid_, because it's just confusing and complex:
- "git fetch somerepo branch1:mybranch1 branch2:mybranch2"
This works, and I'm sure it's useful, and I've even used it (usually
with just one branch, though), but let's face it - it's too damn
complicated to be anything you want to do _normally_.
So git is definitely powerful, but I think some people have looked at the
_complicated_ cases more than the simple cases (ie maybe people have
looked too much at that last case, not realizing that there really isn't
much reason to use it - and FETCH_HEAD is one big reason why you seldom
need the complicated format).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-16 23:08 ` Linus Torvalds
@ 2006-11-16 23:36 ` Johannes Schindelin
2006-11-17 0:49 ` Linus Torvalds
2006-11-16 23:40 ` Han-Wen Nienhuys
2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
> On Thu, 16 Nov 2006, Johannes Schindelin wrote:
> >
> > - a terrible UI.
>
> Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
It is a terrible UI, because it was not that obvious to me. And I consider
myself not a git newbie.
Besides, it is not really a temporary branch. If it was, the pull would
_not_ download all these objects again, would it?
> > _Also_, git-pull not storing the fetched branches at least temporarily
> > often annoyed me: the pull did not work, and the SHA1 was so far away I
> > could not even scroll to it.
>
> Again, why didn't you use FETCH_HEAD?
Because I am a Jar-HEAD?
> If the user doesn't give us a head to write to, we clearly MUST NOT write
> to any long-term branch. That would be a _horrible_ mistake.
I was _not_ suggesting a long-term branch. Just a way to do-what-i-want
and not waste bandwidth.
> And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT
> overwrite any existing branches unless explicitly told to do so by the
> user.
Guess three times why I did not post the patches.
But the real problem is not necessarily the behaviour; it is the obscure
fashion of the behaviour. You may not understand that problem, because you
were there from the beginning. You saw the big-bang and how all the
quarks formed all of a sudden, and how matter and eventually planets
and suns came into being.
But others (me included) were not there. Or they did not really watch. And
now they see all these creatures, and plants, and bacteria, and they do
not understand how these are all connected, because of that. And now they
think "wow that must have been some intelligent design, and really a
miracle, and I cannot understand how it works." But that is not true
(the latter part of course).
There is something to be said about the simplicity of Mercurial. It's
inner workings may suck, but people get easily attracted by it.
I do not claim we should imitate Mercurial, or even hide the index (even
if I sometimes wonder if the index is not just a clever way to accelerate
commits, and nothing more).
> So I really don't see your point.
>
> A lot of the complaints seem to not be about the interfaces, but about
> people not _understanding_ and knowing what the interfaces do.
But the interfaces should be usable interfaces! They should _explain_ what
they do. Other software does so, it can't be _that_ hard.
> git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
I find that quite easy to understand. Why? Because I happen to _know_ the
syntax of -merge and -fmt-merge-msg. For similar reasons I _understand_
why -pull behaves like it does. But others don't; they will shudder and
then run.
Maybe it is not important that -pull fetches all objects all over again.
But it _is_ important to make things like merging branches (local or
remote) trivial. It _is_ important to make the user experience be fun.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 23:36 ` Johannes Schindelin
@ 2006-11-17 0:49 ` Linus Torvalds
2006-11-17 1:08 ` Carl Worth
2006-11-17 1:22 ` Johannes Schindelin
0 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17 0:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
On Fri, 17 Nov 2006, Johannes Schindelin wrote:
> > Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
>
> It is a terrible UI, because it was not that obvious to me. And I consider
> myself not a git newbie.
Heh. The "temporary branches" are actually the _original_ branches as far
as git is concerned. The long-term branches only came later.
So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more
fundamental than any long-term branch has ever been, and maybe they should
be taught first as such.
So you're newbie enough that you've only seen those new-fangled "real"
branches.
When I was young, we had to walk to school up-hill in three feet of snow
every day. And we _liked_ our FETCH_HEAD's.
> Besides, it is not really a temporary branch. If it was, the pull would
> _not_ download all these objects again, would it?
Well, exactly because they are temporary, we can't actually trust the
objects they point to. They have no "real" long-term life, so no, I'm
afraid that we always will have to re-fetch the objects, because fetching
them is the only way to know that we still have them.
That said, we could certainly _make_ them be honored by things like "git
prune" and friends. But yes, they really _are_ temporary branches right
now, and part of the meaning of that "temporary" is exactly the fact that
git fetch will not trust that you still have the objects.
For example, if you used one of the old-fashioned commit walkers, maybe we
got the initial commit, but we may not have gotten the whole _chain_. See?
Temporary branch indeed.
> > Again, why didn't you use FETCH_HEAD?
>
> Because I am a Jar-HEAD?
Well, we clearly should document them better. Anybody?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 0:49 ` Linus Torvalds
@ 2006-11-17 1:08 ` Carl Worth
2006-11-17 1:22 ` Johannes Schindelin
1 sibling, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 1:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Han-Wen Nienhuys, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]
On Thu, 16 Nov 2006 16:49:29 -0800 (PST), Linus Torvalds wrote:
> So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more
> fundamental than any long-term branch has ever been, and maybe they should
> be taught first as such.
Older in git's history as it developed is not a good match for more
fundamental in the concepts that git makes available today.
> > > Again, why didn't you use FETCH_HEAD?
> >
> > Because I am a Jar-HEAD?
>
> Well, we clearly should document them better. Anybody?
I for one am totally unsatisfied with this approach.
Here's an operations I'd like to be able to do:
Given a (URL, branch) pair I'd like I'd like to be able to
investigate that code, (say with the fancy new "read-only
branch" concept we've been talking about).
What are my options for this operation? What might a new user's
reaction to them be?
a) git fetch URL branch
git checkout FETCH_HEAD
This is really ugly. A name like "FETCH_HEAD" is something a user
should really never have to type. It's hideously hard to type and
has no natural discoverability. Yuck, yuck, yuck.
b) vi .git/remotes/something
git fetch something
git checkout branch
Also yuck. I hope it's obvious that having to edit a configuration
for this simple operation is a non-starter.
c) git fetch URL branch:local-branch
git checkout local-branch
We're getting close to the desired functionality now, but the UI
makes users cringe? "What's that : for?" Why do I need another
name?" etc. Linus, you yourself said this is a form that users
should generally avoid.
d) git fetch URL branch:branch
git checkout branch
One step closer. But there's still that goofy extra ':' and a
doubled name in the first command. "Why is that there? Git sure is
weird...".
What I think this operation should look like is:
git fetch URL branch
git checkout branch
And the fetch should just complain if there's a name clash. Or better,
the fetch should tuck the fetched branch into its own URL-specific
namespace and then the checkout command can kindly prompt if there is
any ambiguity:
Which "branch" do you want?
local/branch
remote-url/branch
or whatever.
See? That's what reasonable UI should look like.
Please feel free to keep using vestiges like FETCH_HEAD as much as you
like, but please don't recommend documenting them better as a solution
for UI warts in git. (If you would only look at these warts closer,
you'd see they have some lovely locks of hair on them.)
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 0:49 ` Linus Torvalds
2006-11-17 1:08 ` Carl Worth
@ 2006-11-17 1:22 ` Johannes Schindelin
2006-11-17 1:52 ` Petr Baudis
1 sibling, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17 1:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
> On Fri, 17 Nov 2006, Johannes Schindelin wrote:
>
> > Besides, it is not really a temporary branch. If it was, the pull would
> > _not_ download all these objects again, would it?
>
> Well, exactly because they are temporary, we can't actually trust the
> objects they point to.
Nonono.
We made _sure_ that FETCH_HEAD is only written once _all_ the objects were
received. So, actually, we _can_, and we _should_ trust the objects they
point to!
Or did I miss something?
> For example, if you used one of the old-fashioned commit walkers, maybe we
> got the initial commit, but we may not have gotten the whole _chain_. See?
Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
is, that's a bug.
Ciao,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 1:22 ` Johannes Schindelin
@ 2006-11-17 1:52 ` Petr Baudis
2006-11-17 2:16 ` Johannes Schindelin
0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-17 1:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
> On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > For example, if you used one of the old-fashioned commit walkers, maybe we
> > got the initial commit, but we may not have gotten the whole _chain_. See?
>
> Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
> is, that's a bug.
It may be updated and then things may break _afterwards_. git-prune will
happily blow anything referenced by FETCH_HEAD, it's not considered by
the fsck-objects reachability analysis.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-17 1:52 ` Petr Baudis
@ 2006-11-17 2:16 ` Johannes Schindelin
0 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-17 2:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
Hi,
On Fri, 17 Nov 2006, Petr Baudis wrote:
> On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
> > On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > > For example, if you used one of the old-fashioned commit walkers, maybe we
> > > got the initial commit, but we may not have gotten the whole _chain_. See?
> >
> > Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
> > is, that's a bug.
>
> It may be updated and then things may break _afterwards_. git-prune will
> happily blow anything referenced by FETCH_HEAD, it's not considered by
> the fsck-objects reachability analysis.
This actually underlines my point: FETCH_HEAD is no _real_ branch, not
even a temporary one. If it was, git-prune would not lose the related
objects.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-16 23:08 ` Linus Torvalds
2006-11-16 23:36 ` Johannes Schindelin
@ 2006-11-16 23:40 ` Han-Wen Nienhuys
2 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 23:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
> A lot of the complaints seem to not be about the interfaces, but about
> people not _understanding_ and knowing what the interfaces do. If you were
From the point of view of a user, there is not really a difference
between the two. As a user, you form a mental model of how things
work by looking at the interface. If the interface is bad, the user
creates a faulty model in his head, and starts doing things that
are perfectly logical in the faulty model, but stupid and silly when
you consider the actual internals.
A nice book about this is "The Design of Everyday Things" by Donald
Norman.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 18:21 ` Linus Torvalds
` (2 preceding siblings ...)
2006-11-16 22:21 ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
@ 2006-11-16 23:32 ` Han-Wen Nienhuys
2006-11-17 12:53 ` Jakub Narebski
3 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 23:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
>> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
>> remote one. The example I gave was about locally creating a single
>> project repo from a remote multiproject repo.
>
> Ahh.
>
> Ok, try the patch I just sent out, and see if it works for you. It
> _should_ allow you to do exactly that
I'm leaving for a short holiday tomorrow, but will do when I come back.
>> From UI perspective it would be nice if this could also be done with clone,
>>
>> git clone . ssh+git://....
>
> The creation of a new archive tends to need special rights (with _real_
> ssh access and a shell you could do it, but "ssh+git" really means "git
> protocol over a connection that was opened with ssh, but doesn't
> necessarily have a real shell at the other end").
What happens on savannah is that the sysadmins set up an empty GIT
repo with access, and leave it to you to push the stuff. Of course,
if the initial import gets packed automatically, that's also ok.
> So I think the above syntax is actually not a good one, because it cannot
> work in the general case. It's much better to get used to setting up a
> repo first, and then pushing into it, and just accepting that it's a
> two-phase thing.
Perhaps ; from a UI viewpoint, it would be nice though, even if it
were aliased to a simple push. (Darcs has a get command analogous to
git-clone, but also a put command to which git lacks the equivalent).
>> * why are objects downloaded twice? If I do
>>
>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
>>
>> it downloads stuff, but I don't get a branch.
> [..]
>> If I then do
>>
>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>>
>> it downloads the same stuff again.
>
> Right. So you can either
> [..]
> See?
No, I don't understand. In the fetch all the objects with their SHA1s
were already downloaded. I'd expect that the fetch with a refspec
would simply write a HEAD and a refs/heads/master, and notice that all
the actual data was already downloaded, and doesn't download it again.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
2006-11-16 23:32 ` Han-Wen Nienhuys
@ 2006-11-17 12:53 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 12:53 UTC (permalink / raw)
To: git
Han-Wen Nienhuys wrote:
> Linus Torvalds escreveu:
>>> If I then do
>>>
>>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>>>
>>> it downloads the same stuff again.
>>
>> Right. So you can either
>> [..]
>> See?
>
> No, I don't understand. In the fetch all the objects with their SHA1s
> were already downloaded. I'd expect that the fetch with a refspec
> would simply write a HEAD and a refs/heads/master, and notice that all
> the actual data was already downloaded, and doesn't download it again.
But how git is to know that you have this already downloaded? Git compares
_refs_ on the local and remote side to calculate what needs to be
downloaded. It does not (and should not) send all the objects IDs local
side has.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:17 ` Linus Torvalds
2006-11-16 17:40 ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
@ 2006-11-16 17:57 ` Linus Torvalds
2006-11-16 18:27 ` Junio C Hamano
2006-11-16 18:28 ` Linus Torvalds
2006-11-16 18:13 ` Carl Worth
2 siblings, 2 replies; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 17:57 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> (And the real reason for that is simple: "git pull" simply wants to have
> something to _start_ with. It's not hugely fundamental, it's just how it
> was written).
Here's a very lightly tested patch that allows you to use "git pull" to
populate an empty repository.
I'm not at all sure this is necessarily the nicest way to do it, but it's
fairly straightforward.
Junio, what do you think?
Linus
---
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..7e5cee2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,10 +44,10 @@ do
shift
done
-orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD 2> /dev/null)
git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
-curr_head=$(git-rev-parse --verify HEAD)
+curr_head=$(git-rev-parse --verify HEAD 2> /dev/null)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
+ if test -z "$orig_head"
+ then
+ echo >&2 "Cannot merge multiple branches into empty head"
+ exit 1
+ fi
var=`git-repo-config --get pull.octopus`
if test -n "$var"
then
@@ -95,6 +100,12 @@ case "$merge_head" in
;;
esac
+if test -z "$orig_head"
+then
+ git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
+ exit
+fi
+
case "$strategy_args" in
'')
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:57 ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 18:27 ` Junio C Hamano
2006-11-16 18:28 ` Linus Torvalds
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 18:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 16 Nov 2006, Linus Torvalds wrote:
>>
>> (And the real reason for that is simple: "git pull" simply wants to have
>> something to _start_ with. It's not hugely fundamental, it's just how it
>> was written).
>
> Here's a very lightly tested patch that allows you to use "git pull" to
> populate an empty repository.
>
> I'm not at all sure this is necessarily the nicest way to do it, but it's
> fairly straightforward.
>
> Junio, what do you think?
Yeah, I talked about making "merge" treat missing HEAD as a
special case of fast forward, but I like yours better. It is a
lot cleaner and to the point.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:57 ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 18:27 ` Junio C Hamano
@ 2006-11-16 18:28 ` Linus Torvalds
2006-11-16 19:47 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 18:28 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Thu, 16 Nov 2006, Linus Torvalds wrote:
> @@ -95,6 +100,12 @@ case "$merge_head" in
> ;;
> esac
>
> +if test -z "$orig_head"
> +then
> + git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
> + exit
> +fi
> +
So this is the place that probably wants a "git-checkout" before the
exit, otherwise you'd (illogically) have to do it by hand for that
particular case.
Of course, we should _not_ do it if the "--bare" flag has been set, so you
migth want to tweak the exact logic here.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 18:28 ` Linus Torvalds
@ 2006-11-16 19:47 ` Junio C Hamano
2006-11-16 19:53 ` Linus Torvalds
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 19:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, git
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 16 Nov 2006, Linus Torvalds wrote:
>> @@ -95,6 +100,12 @@ case "$merge_head" in
>> ;;
>> esac
>>
>> +if test -z "$orig_head"
>> +then
>> + git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1
>> + exit
>> +fi
>> +
>
> So this is the place that probably wants a "git-checkout" before the
> exit, otherwise you'd (illogically) have to do it by hand for that
> particular case.
>
> Of course, we should _not_ do it if the "--bare" flag has been set, so you
> migth want to tweak the exact logic here.
As you said, pull inherently involve a merge which implies the
existence of associated working tree, so I do not think there is
any room for --bare to get in the picture. We already do the
checkout when we recover from a fetch that is used incorrectly
and updated the current branch head underneath us.
To give the list a summary of the discussion so far, here is a
consolidated patch.
-- >8 --
From: Linus Torvalds <torvalds@osdl.org>
Subject: git-pull: allow pulling into an empty repository
We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet. Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-pull.sh b/git-pull.sh
index ed04e7d..e23beb6 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,10 +44,10 @@ do
shift
done
-orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
+orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
-curr_head=$(git-rev-parse --verify HEAD)
+curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
+ if test -z "$orig_head"
+ then
+ echo >&2 "Cannot merge multiple branches into empty head"
+ exit 1
+ fi
var=`git-repo-config --get pull.octopus`
if test -n "$var"
then
@@ -95,6 +100,13 @@ case "$merge_head" in
;;
esac
+if test -z "$orig_head"
+then
+ git-update-ref -m "initial pull" HEAD $merge_head "" &&
+ git-read-tree --reset -u HEAD || exit 1
+ exit
+fi
+
case "$strategy_args" in
'')
strategy_args=$strategy_default_args
^ permalink raw reply related [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 17:17 ` Linus Torvalds
2006-11-16 17:40 ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
2006-11-16 17:57 ` Cleaning up git user-interface warts Linus Torvalds
@ 2006-11-16 18:13 ` Carl Worth
2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-16 18:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Thu, 16 Nov 2006 09:17:32 -0800 (PST), Linus Torvalds wrote:
> So the way you'd normally set up a single repo that contains multiple
> other existing repositories is to basically start with one ("git clone")
> and then add the other branches and "git fetch" them.
For that we'd also need a way for clone to be able to fetch just a
single branch, and not all of them as well.
There is some clone vs. fetch asymmetry here that has annoyed me for a
while, and that I don't think has been mentioned in this thread
yet. Namely:
clone: can only be executed once, fetches all branches, "remembers"
URLs for later simplified use
fetch: can be executed many times, fetches only named branches,
doesn't remember anything for later
I've often been in the situation where I cloned a long time ago, but
I'd like to be able to fetch everything that I would get if I were to
start a fresh clone.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:12 ` Linus Torvalds
2006-11-16 10:31 ` Junio C Hamano
2006-11-16 10:45 ` Han-Wen Nienhuys
@ 2006-11-16 23:00 ` Johannes Schindelin
2006-11-16 23:22 ` Linus Torvalds
2 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-16 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
Hi,
On Wed, 15 Nov 2006, Linus Torvalds wrote:
> Peopel seem to believe that changign a few names or doing other totally
> _minimal_ UI changes would somehow magically make things understandable.
Never ever underestimate pet peeves. If we give many people an obvious
reason (however trivial and bike-shed-coloured) to complain, they will
complain.
If we pull (pun intended) that reason away under their collective
backsides, they will have to find another reason to complain. But by the
time they found something, they will already be happy git users!
But since you just provided a patch to make life easier on non-gitters, I
guess you agree with that already.
And hopefully you also agree that enhancing the syntax of git-merge to
grok "git-merge [-m message] <branch>" and "git-merge [-m message]
<url-or-remote> <branch>" would be a lovely thing, luring even more
people into using git.
Maybe they even start complaining about subversion and CVS calling a merge
"update", who knows?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 23:00 ` Johannes Schindelin
@ 2006-11-16 23:22 ` Linus Torvalds
2006-11-17 0:05 ` Han-Wen Nienhuys
0 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-16 23:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
On Fri, 17 Nov 2006, Johannes Schindelin wrote:
>
> Never ever underestimate pet peeves. If we give many people an obvious
> reason (however trivial and bike-shed-coloured) to complain, they will
> complain.
I do actually think that this discussion has been informative, partly
because I never even realized that some people would ever think to do
"init-db" + "pull".
Making things like that work is easy enough, it's just that I never saw
any point until people complained. And when they complained, the initial
complaint wasn't actually obvious. Only when Han-Wen actually gave
something that didn't work, was it clear that the real issue wasn't so
much _naming_, as just expectations about the _work_flow_.
> And hopefully you also agree that enhancing the syntax of git-merge to
> grok "git-merge [-m message] <branch>" and "git-merge [-m message]
> <url-or-remote> <branch>" would be a lovely thing, luring even more
> people into using git.
I definitely think we can make "git merge" have a more pleasant syntax.
I'm just still not sure that people should actually use it ;)
My real point was/is that usually it's really not the "naming details"
that people _really_ have problems with. The real problems tend to be in
learning a new workflow.
We can make some of those workflows easier, but I would heartily recommend
that people not worry about naming of "pull" vs "fetch", because that's
almost certainly not really the issue. Instead, if you have a problem,
rather than concentrating on the names of the programs, say:
- what do you want to get done.
Most likely it's _trivial_ to do with git, it's just that somebody used
the wrong approach, and then it didn't work at all.
- give actual examples of a workflow that didn't work or was complex.
(again, the "init-db" + "pull" example).
And yes, in many cases, it might well be a case of "sure, we can make
that _other_ workflow work too". But somebody like me, who has used git
for a year and a half, and used BK before it, probably simply uses a
different workflow than somebody who comes from CVS.
For example, I suspect that your gripe with "git fetch" was just from
using it in a really awkward manner. Maybe we could make your workflow
work with git too, but maybe it really already (and always) did, you just
used a particular tool in a way that made the use be really really
painful.
Sometimes it's just a question of "ok, use it like _this_, and now it's
actually really simple". Other times it's "ok, I didn't even realize that
you wanted to use it like _that_, and yeah, that's incredibly
inconvenient, and we can change it".
I just got involved in this discussion because I thought people were
talking about all the wrong things. Command naming really can't be _that_
big of a deal. I really don't believe that we should have some people use
"gh" instead of "git" just because they think "pull" should mean not to
merge or something.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 23:22 ` Linus Torvalds
@ 2006-11-17 0:05 ` Han-Wen Nienhuys
2006-11-17 0:13 ` Junio C Hamano
` (3 more replies)
0 siblings, 4 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17 0:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
> My real point was/is that usually it's really not the "naming details"
> that people _really_ have problems with. The real problems tend to be in
> learning a new workflow.
I agree that discussions on naming may cloud the issue, but "learning
the workflow" implies that people should adapt to the limitations of
their tools. That's only a viable stance when the tools are finished
and completely perfect.
Until that time, it would be good goal to remove all idiosyncrasies,
all gratuitious asymetries and needless limitations in the commands of
git, eg.
- clone but not a put-clone,
- pull = merge + fetch, but no command for merge + throw
- clone for getting all branches of a repo, but no command for
updating all branches of a repo.
Of course, when all warts are fixed, backward compatibility will force
us to choose some new names. At that point, a discussion on naming is
in place.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:05 ` Han-Wen Nienhuys
@ 2006-11-17 0:13 ` Junio C Hamano
2006-11-17 0:27 ` Han-Wen Nienhuys
` (2 more replies)
2006-11-17 0:39 ` Linus Torvalds
` (2 subsequent siblings)
3 siblings, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 0:13 UTC (permalink / raw)
To: hanwen; +Cc: git
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> - clone but not a put-clone,
What's put-clone? Care to explain?
> - pull = merge + fetch, but no command for merge + throw
What's merge+throw? Care to explain?
> - clone for getting all branches of a repo, but no command for
> updating all branches of a repo.
This one I can understand, but how would you propose to "update
all branches", in other words what's your design for mapping
remote branch names to local branch namespaces?
It would be nice if the design does not straightjacket different
repository layouts different people seem to like, but I think it
would be Ok to limit ourselves only to support the straight
one-to-one mapping and support only separate-remote layout.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:13 ` Junio C Hamano
@ 2006-11-17 0:27 ` Han-Wen Nienhuys
2006-11-17 0:35 ` Petr Baudis
2006-11-17 0:37 ` Carl Worth
2006-11-17 1:25 ` Carl Worth
2 siblings, 1 reply; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano escreveu:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> - clone but not a put-clone,
>
> What's put-clone? Care to explain?
put clone would be the putative inverse of clone, ie. make a clone of
a local repository on a remote server.
>> - pull = merge + fetch, but no command for merge + throw
>
> What's merge+throw? Care to explain?
throw is the hypothetical opposite of fetch. I agree that this is
academical, because it's logical to only allow fast-forwards for
sending revisions.
>> - clone for getting all branches of a repo, but no command for
>> updating all branches of a repo.
>
> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?
>
> It would be nice if the design does not straightjacket different
> repository layouts different people seem to like, but I think it
> would be Ok to limit ourselves only to support the straight
> one-to-one mapping and support only separate-remote layout.
I think the whole clone design is a bit broken, in that the "master"
branch gets renamed or copied to "origin", but all of the other
branches remain unchanged in their names.
It's more logical for clone to either
* leave all names unchanged
* put all remote branches into a subdirectory. This would also make
it easier to track branches from multiple servers.
At present, I have in my build-daemon the following branches,
cvs-head-repo.or.cz-lilypond.git
hanwen-repo.or.cz-lilypond.git
hwn-jcn-repo.or.cz-lilypond.git
lilypond_1_0-repo.or.cz-lilypond.git
lilypond_1_2-repo.or.cz-lilypond.git
lilypond_1_4-repo.or.cz-lilypond.git
lilypond_1_6-repo.or.cz-lilypond.git
lilypond_1_8-repo.or.cz-lilypond.git
lilypond_2_0-repo.or.cz-lilypond.git
lilypond_2_2-repo.or.cz-lilypond.git
lilypond_2_3_2b-repo.or.cz-lilypond.git
lilypond_2_3_5b-repo.or.cz-lilypond.git
lilypond_2_4-repo.or.cz-lilypond.git
lilypond_2_6-repo.or.cz-lilypond.git
lilypond_2_8-repo.or.cz-lilypond.git
master-git.sv.gnu.org-lilypond.git
master-hanwen
master-repo.or.cz-lilypond.git
origin-repo.or.cz-lilypond.git
stable
stable-2.10
stable--2.10-git.sv.gnu.org-lilypond.git
It would solve lots of problems for me if cloning and fetching would
put branches into a subdirectory, ie.
git clone git://repo.or.cz/lilypond.git
leads to branches
repo.or.cz/lilypond_2_8
repo.or.cz/lilypond_2_6
repo.or.cz/lilypond_2_4
repo.or.cz/master
(etc..)
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:27 ` Han-Wen Nienhuys
@ 2006-11-17 0:35 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-17 0:35 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Fri, Nov 17, 2006 at 01:27:53AM CET, Han-Wen Nienhuys wrote:
> put clone would be the putative inverse of clone, ie. make a clone of
> a local repository on a remote server.
So effectively to tell git push not to unpack on the remote side, and to
push all branches and relevant tags.
..snip..
> It's more logical for clone to either
>
> * leave all names unchanged
>
> * put all remote branches into a subdirectory. This would also make
> it easier to track branches from multiple servers.
>
> At present, I have in my build-daemon the following branches,
>
> cvs-head-repo.or.cz-lilypond.git
> hanwen-repo.or.cz-lilypond.git
> hwn-jcn-repo.or.cz-lilypond.git
> lilypond_1_0-repo.or.cz-lilypond.git
> lilypond_1_2-repo.or.cz-lilypond.git
> lilypond_1_4-repo.or.cz-lilypond.git
> lilypond_1_6-repo.or.cz-lilypond.git
> lilypond_1_8-repo.or.cz-lilypond.git
> lilypond_2_0-repo.or.cz-lilypond.git
> lilypond_2_2-repo.or.cz-lilypond.git
> lilypond_2_3_2b-repo.or.cz-lilypond.git
> lilypond_2_3_5b-repo.or.cz-lilypond.git
> lilypond_2_4-repo.or.cz-lilypond.git
> lilypond_2_6-repo.or.cz-lilypond.git
> lilypond_2_8-repo.or.cz-lilypond.git
> master-git.sv.gnu.org-lilypond.git
> master-hanwen
> master-repo.or.cz-lilypond.git
> origin-repo.or.cz-lilypond.git
> stable
> stable-2.10
> stable--2.10-git.sv.gnu.org-lilypond.git
>
> It would solve lots of problems for me if cloning and fetching would
> put branches into a subdirectory, ie.
>
> git clone git://repo.or.cz/lilypond.git
>
> leads to branches
>
> repo.or.cz/lilypond_2_8
> repo.or.cz/lilypond_2_6
> repo.or.cz/lilypond_2_4
> repo.or.cz/master
> (etc..)
That's basically exactly what git clone --use-separate-remote should do.
Now only if it would become the default... :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:13 ` Junio C Hamano
2006-11-17 0:27 ` Han-Wen Nienhuys
@ 2006-11-17 0:37 ` Carl Worth
2006-11-17 1:25 ` Carl Worth
2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: hanwen, git
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Thu, 16 Nov 2006 16:13:44 -0800, Junio C Hamano wrote:
> > - clone for getting all branches of a repo, but no command for
> > updating all branches of a repo.
I want this one as well.
> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?
As long as its consistent with "clone" I'll be happy, (I think as part
of a separate topic we need to fix the mappings in clone, see
--use-separate-remotes as default and related).
The current case is really annoying where I have to throw use clone
into a new repository just to get everything, rather than just being
able to fetch everything into the repository I already have.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:13 ` Junio C Hamano
2006-11-17 0:27 ` Han-Wen Nienhuys
2006-11-17 0:37 ` Carl Worth
@ 2006-11-17 1:25 ` Carl Worth
2 siblings, 0 replies; 601+ messages in thread
From: Carl Worth @ 2006-11-17 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: hanwen, git
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
On Thu, 16 Nov 2006 16:13:44 -0800, Junio C Hamano wrote:
> This one I can understand, but how would you propose to "update
> all branches", in other words what's your design for mapping
> remote branch names to local branch namespaces?
What I want here is a command "git update" that fetches and
fast-forwards the all branches which are designated as "tracking" a
branch in some known remote repository. And git-clone would setup all
branches appropriately so that they would be updated by git-update.
Additionally, it would be nice if git-update would also create new
tracking branches for all remotes repositories that had been
designated as being tracked, (and git-clone would do this as well).
There should also be a mechanism to easily create new tracking support
for specific branches or all branches of a repository, (could be "git
fetch URL branch" or "git fetch --all URL", for example).
With this kind of setup, I would use "git update" regularly, and only
ever merge locally. And by definition merging with any local tracking
branch would have just as much information available as "pull URL
branch" so the message would be the same.
I've been using git for 10-11 months, so I think I understand the
models fairly well, and I'd be really happy with a setup like that. I
also have talked with a fair number of (non-git-using) users who think
git is confusing, but I think would find the above scenario just fine.
In this scenario, git pull would still work just fine, but it would
also be much easy to teach a workflow that didn't use pull at all, so
if there's any git-pull confusion that's an actual problem, it could
be avoided.
Junio, what do you think of a setup something like that? I really
don't want to create a command other than "git" to implement it.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:05 ` Han-Wen Nienhuys
2006-11-17 0:13 ` Junio C Hamano
@ 2006-11-17 0:39 ` Linus Torvalds
2006-11-17 0:52 ` Han-Wen Nienhuys
2006-11-17 1:34 ` Michael K. Edwards
2006-11-23 2:52 ` Horst H. von Brand
3 siblings, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-17 0:39 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git
On Fri, 17 Nov 2006, Han-Wen Nienhuys wrote:
>
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.
Well, a lot of the assymmetries aren't actually gratuitous at all.
> - clone but not a put-clone,
As mentioned, in order to "put-clone", you generally have to "create"
first, so the "put-clone" really makes no sense.
The _true_ reverse is really your
- "git init-db" on both sides
- "git pull" (your workflow ;) on receiving
- "git push" on sending.
The fact that we can do "git clone" on the _receiving_ side is an
assymmetry, but it's not gratutous: when receiving we don't need any extra
permissions or setup to create a new archive. In contrast, when sending,
you do have to have that "get permission to create new archive" phase.
> - pull = merge + fetch, but no command for merge + throw
Again, this is not gratuitous, and the reason is very similar: when you
pull, you're pulling into something that _you_ control and _you_ have
access to, namely your working directory. In order to merge you have to
have the ability to fix up conflicts (whether automatically or manually),
and this is something that you _fundamentally_ can only do when you own
the repo space.
Again, when you do "push", the reason you can't merge is not a "gratuitous
assymmetry", but a _fundamental_ assymmetry: by definition, you're pushing
to a _remote_ thing, and as such you can't merge, because you can't fix up
any merge problems.
See?
In many ways, if you want _symmetry_, you need to make sure that the
_cases_ are symmetrical. If you have ssh shell access, you can often do
that, and the "reverse" of a "git pull" is actually just another "git
pull" from the other side:
ssh other-side "cd repo ; git pull back"
Now they really _are_ symmetrical: "git pull" is really in many ways ITS
OWN reverse operation.
But "push" and "pull" _fundamentally_ aren't symmetric operations, and you
simply cannot possibly make them symmetric. Any system that tries would be
absolutely horrible to use, exactly because it would be either:
- making local/remote operations totally equivalent
This sounds like a "good" thing, but from a real user perspective it's
actually horribly horribly bad. Knowing the difference between local
and remote is what allows a lot of performance optimizations, and a lot
of security. Your local repo is _yours_, and nobody can take that away
from you, and that's a really fundamental reason for why the symmetry
cannot exist, and why local/remote operations MUST NOT be something
that you can mix without thinking about them,
- limit local operations in a way to make them effectively unusable and
unscriptable.
You'd basically have to do everything even _locally_ through some
server interface, and you'd not be allowed to ever touch your local
checked-out repository directly. Again: local repositories really _are_
special, because you can touch the checked out copy. If you try to
suppress that, you're screwed.
> - clone for getting all branches of a repo, but no command for
> updating all branches of a repo.
As in sending? Sure there is: use "git push --all". It will push out every
branch (and tag) you have. Add "--force" if you want to make sure that it
also pushed out branches even if the result isn't a strict superset (of
course, the receiving end may actually end up refusing to take it, there's
a option for the receiver to say "I will refuse any update that isn't a
strict superset of what I had").
If you mean as in "receiving new branches", then yeah, you do have to
script it, with some fairly trivial "git ls-remote" to make sure you get
the new remotes.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:39 ` Linus Torvalds
@ 2006-11-17 0:52 ` Han-Wen Nienhuys
0 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17 0:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
Linus Torvalds escreveu:
> The fact that we can do "git clone" on the _receiving_ side is an
> assymmetry, but it's not gratutous: when receiving we don't need any extra
> permissions or setup to create a new archive. In contrast, when sending,
> you do have to have that "get permission to create new archive" phase.
>
>> - pull = merge + fetch, but no command for merge + throw
>
> Again, this is not gratuitous, and the reason is very similar: when you
> pull, you're pulling into something that _you_ control and _you_ have
>But "push" and "pull" _fundamentally_ aren't symmetric operations, and you
>simply cannot possibly make them symmetric.
Point taken; thank you.
In that case, we're full circle with the command naming issues. Push
and pull are fundamentally asymmetric operations, but then a
consistent UI would dictate that they wouldn't be named symmetrically,
as they are now.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:05 ` Han-Wen Nienhuys
2006-11-17 0:13 ` Junio C Hamano
2006-11-17 0:39 ` Linus Torvalds
@ 2006-11-17 1:34 ` Michael K. Edwards
2006-11-17 6:42 ` Michael K. Edwards
2006-11-23 2:52 ` Horst H. von Brand
3 siblings, 1 reply; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-17 1:34 UTC (permalink / raw)
To: git
I think there's a fundamental assumption built into the design of git
that most programmers accustomed to a corporate environment don't
understand. Namely, that each programmer owns his or her entire
"repository", and can do whatever he or she darn well pleases with it
at any time. Go ahead and create hundreds of transient branches as
part of a scripted "merge complexity metric" calculation. Try three
different refactoring strategies on different branches, abandon two of
them, and prune them months later. And generally use the power of the
SCM to juggle a lot of things at once, because there's no sysadmin
gatekeeper stopping you, and the thing is designed and coded scalably
so it doesn't grind to a halt as soon as everyone has dozens of
private branches.
Even if you do find a way to push git in a direction that it doesn't
scale, it's no one's problem but your own -- people who pull from you
are pulling the _content_ on the branches they care about, not the
structure of your repository.
On 11/16/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> I agree that discussions on naming may cloud the issue, but "learning
> the workflow" implies that people should adapt to the limitations of
> their tools. That's only a viable stance when the tools are finished
> and completely perfect.
>
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.
One person's gratuitous asymmetry is another's minimalism. (If the
symmetric thing doesn't make any sense or can't be implemented
scalably, leave it out.) It is more important that git continue to
work than that it appear symmetric without reference to its function.
> - clone but not a put-clone,
What possible use would that be? git is not rsync.
> - pull = merge + fetch, but no command for merge + throw
pull = fetch + merge. It is (almost?) always followed by a judgment
call based on the merge results. merge + throw doesn't make any sense
in terms of the job at hand, which is facilitating human judgments
about whether to accept someone else's work into one's working tree.
> - clone for getting all branches of a repo, but no command for
> updating all branches of a repo.
clone is shorthand for the steps involved in setting up a new
repository with content similar to an existing one. There isn't any
merge involved, and no scope for human judgment, so it's simplest to
clone the whole state of the remote repository (including tags and
branches) and let the user blow away any branches he doesn't need.
But once the clone is done, all of those branches are _truly_ _local_
-- they don't retain any reference to the remote branches, and you can
commit to all of them. The only entry placed in .git/remotes is the
"origin" of the new clone, which is the "master" of the remote
repository. That's for the user's convenience, and is about the only
thing in the new clone that _isn't_ a copy of something in the remote
tree.
So the "update all" process wouldn't look anything like a clone, it
would be a fetch and replay of each remote branch onto the
corresponding local branch. You and Carl seem to want "git clone" not
only to copy the heads of the remote branches but to populate
.git/remotes with trackers for all of those branches, and then to
start each "git update" by polling all of the remote repositories to
see if branches have been created or deleted, then pull every branch
in sight. What do you do when "upstream" creates a branch with the
same name as a local branch you have created? How do you deal with
branch points that don't exist in your repository because you touched
one of the "tracker" branches between pulls?
In short, if you want a local, read-only tracker for a whole remote
repository instead of a branch that's actually published to you (and
maintained accordingly), you might consider s/git/rsync/.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 1:34 ` Michael K. Edwards
@ 2006-11-17 6:42 ` Michael K. Edwards
2006-11-17 7:32 ` Junio C Hamano
2006-11-17 12:25 ` Jakub Narebski
0 siblings, 2 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-17 6:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
On 11/16/06, Michael K. Edwards <medwards.linux@gmail.com> wrote
> The only entry placed in .git/remotes is the
> "origin" of the new clone, which is the "master" of the remote
> repository. That's for the user's convenience, and is about the only
> thing in the new clone that _isn't_ a copy of something in the remote
> tree.
Actually, this "origin" entry does contain "Pull:" lines for all of
the branches that were cloned, so that "git pull" fetches and merges
updates to all of these branches. (If upstream is in the habit of
reverting things, you may need "git pull -f"; I just did that on the
git repo to handle a failure to fast-forward on the "pu" branch.)
Presumably "git branch -D" should inspect everything under
.git/remotes to see whether one or more Pull: lines need to be deleted
along with the branch. Currently, it looks like "remotes" entries are
created only by "git clone" or by hand. Junio, are there any plans to
manage the contents of "remotes" through the tool instead of by hand?
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 6:42 ` Michael K. Edwards
@ 2006-11-17 7:32 ` Junio C Hamano
2006-11-18 1:24 ` Michael K. Edwards
2006-11-17 12:25 ` Jakub Narebski
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 7:32 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> Presumably "git branch -D" should inspect everything under
> .git/remotes to see whether one or more Pull: lines need to be
> deleted along with the branch.
I am not sure what you mean. .git/remotes files do not describe
any relationship between local branches (and that is where one
of the problem raised in recent thread -- pull does not notice
on which branch you are on and change its behaviour depending on
it), so I do not think there is anything gained for "git branch
-D" by going through them.
> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand. Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?
I muttered something in a near-by thread
Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
I am reasonably sure a separate tool (what I tentatively called
"maint-remote" in the message) is necessary, because, while it
would be relatively easy to make "git fetch" and friends to add
new mappings in the default way under a new option, people with
different workflows would want differnt "default mappings", and
adding new mappings for _all_ remote branches is useful only for
people who work in one particular way (namely, the CVS-style
"the central distribution point is where everybody meet" model).
The tool, under "interactive" mode, would probably take one
parameter, the short name of a remote ($name), and would give
you a form to update its URL:, shows ls-remote output against
that repository and would let you:
- update the URL: which would probably cause the ls-remote to
be re-run;
- remove existing mappings;
- add mappings for a remote branch for which you do not have a
corresponding tracking branch, with a straightforward default
mapping:
refs/heads/$branch:refs/remotes/$name/$branch
But I haven't thought things through yet.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 7:32 ` Junio C Hamano
@ 2006-11-18 1:24 ` Michael K. Edwards
0 siblings, 0 replies; 601+ messages in thread
From: Michael K. Edwards @ 2006-11-18 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On 11/16/06, Junio C Hamano <junkio@cox.net> wrote:
> "Michael K. Edwards" <medwards.linux@gmail.com> writes:
>
> > Presumably "git branch -D" should inspect everything under
> > .git/remotes to see whether one or more Pull: lines need to be
> > deleted along with the branch.
>
> I am not sure what you mean. .git/remotes files do not describe
> any relationship between local branches (and that is where one
> of the problem raised in recent thread -- pull does not notice
> on which branch you are on and change its behaviour depending on
> it), so I do not think there is anything gained for "git branch
> -D" by going through them.
.git/remotes/foo does contain Pull: lines which indicate the local
branch onto which to _fetch_ remote changes. It's the subsequent
_merge_ that doesn't notice which branch you have checked out.
Cheers,
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 6:42 ` Michael K. Edwards
2006-11-17 7:32 ` Junio C Hamano
@ 2006-11-17 12:25 ` Jakub Narebski
1 sibling, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-17 12:25 UTC (permalink / raw)
To: git
Michael K. Edwards wrote:
> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand. Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?
Don't forget quite new work with managing remotes (and per-branch
configuration) in the config instead of separate remotes/ (or even older
branches/) file
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-17 0:05 ` Han-Wen Nienhuys
` (2 preceding siblings ...)
2006-11-17 1:34 ` Michael K. Edwards
@ 2006-11-23 2:52 ` Horst H. von Brand
3 siblings, 0 replies; 601+ messages in thread
From: Horst H. von Brand @ 2006-11-23 2:52 UTC (permalink / raw)
To: hanwen; +Cc: Linus Torvalds, Junio C Hamano, git
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
[...]
> Until that time, it would be good goal to remove all idiosyncrasies,
> all gratuitious asymetries and needless limitations in the commands of
> git, eg.
>
> - clone but not a put-clone,
Lost me there.
> - pull = merge + fetch, but no command for merge + throw
throw + merge (at the remote end, that is)?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:03 ` Linus Torvalds
` (4 preceding siblings ...)
2006-11-16 1:20 ` Han-Wen Nienhuys
@ 2006-11-16 4:30 ` Petr Baudis
5 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 4:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
On Wed, Nov 15, 2006 at 07:03:18PM CET, Linus Torvalds wrote:
> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing. In fact, I think a lot of the
> confusion comes from cogito, not from git - the fact that cogito used
> different names and different syntax was a mistake, I think.
I would agree that having "pull" mean something different in Cogito
than in Git was a bad idea (explanation: historically, for some period
of time Cogito had cg-pull which meant the same as cg-fetch or hg pull;
later it got renamed to cg-fetch). But I'm also happy that Cogito just
does not use the "pull" expression at all currently: "updating" seems to
be a clear and unloaded enough concept for new people. Pull is really
_very_ confusing, with it meaning something different (but not different
enough) in _all_ other systems but BK (which is basically irrelevant
nowadays).
That said, I agree with your argument that changing it in Git now
might just result in more confusion. I'm just trying to explain Cogito's
choice here, and I believe it does no good nor harm to Core Git if it
just uses different name for the concept and avoids the original name at
all (except explaining in the docs that updating in Cogito is what
pulling is in Git).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 2:10 ` Junio C Hamano
2006-11-15 2:27 ` Michael K. Edwards
2006-11-15 4:20 ` Nicolas Pitre
@ 2006-11-15 20:12 ` Petr Baudis
2006-11-15 20:26 ` Nicolas Pitre
2 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-15 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.
How was/is fetch contaminated?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:12 ` Petr Baudis
@ 2006-11-15 20:26 ` Nicolas Pitre
2006-11-15 20:50 ` Linus Torvalds
2006-11-16 1:51 ` Anand Kumria
0 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
On Wed, 15 Nov 2006, Petr Baudis wrote:
> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> > You have to admit both pull and fetch have been contaminated
> > with loaded meanings from different backgrounds. I was talking
> > about killing the source of confusion in the longer term by
> > removing fetch/pull/push, so we are still on the same page.
>
> How was/is fetch contaminated?
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:26 ` Nicolas Pitre
@ 2006-11-15 20:50 ` Linus Torvalds
2006-11-15 21:18 ` Nicolas Pitre
2006-11-16 1:51 ` Anand Kumria
1 sibling, 1 reply; 601+ messages in thread
From: Linus Torvalds @ 2006-11-15 20:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Petr Baudis, Junio C Hamano, git
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> I think "fetch" is sane. Its only problem is a missing symetrical
> counterpart verb, like "get" and "put".
If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
I think "get" and "put" would be bad, just because of confusion with
"sccs get" (ie it has that "get this file" connotations).
Maybe "fetch" and "push" aren't totally diametrically opposite, but
really, I don't think they are that hard to understand either. We do have
the BK legacy of "pull" implying a merge, and that's fairly fundamental.
It's also true that in a lot of usage schenarios, what people actually
_use_ is "pull" and "push", and no, they aren't mirror images (since push
will _not_ do the merge), but at the same time, from a _usage_ standpoint
they really _are_ each others opposites.
You "pull" to get other peoples data into your branch (and once you've
internalized local branches and the merge thing, you know what this
means), and you "push" to push your changes out. It really _is_ the usage
schenario, and using "opposite" words really _does_ make sense.
It's true that _technically_ "fetch" is the opposite of "push", but at the
same time, that really is about technology, not about usage models. You
normally wouldn't do a "git fetch + git push" pair. You _can_ do so, but
it's not the natural way to work - unless you're just doing a mirror
service.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:50 ` Linus Torvalds
@ 2006-11-15 21:18 ` Nicolas Pitre
0 siblings, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 21:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
On Wed, 15 Nov 2006, Linus Torvalds wrote:
>
>
> On Wed, 15 Nov 2006, Nicolas Pitre wrote:
> >
> > I think "fetch" is sane. Its only problem is a missing symetrical
> > counterpart verb, like "get" and "put".
>
> If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
Yeah. You could always throw a branch to your dog.
Or maybe we should introduce the concept of "bones" to GIT in place of
branches? ;-)
> I think "get" and "put" would be bad, just because of confusion with
> "sccs get" (ie it has that "get this file" connotations).
Has SCCS really had a similar level of influence than BK or CVS in that
matter?
> Maybe "fetch" and "push" aren't totally diametrically opposite, but
> really, I don't think they are that hard to understand either. We do have
> the BK legacy of "pull" implying a merge, and that's fairly fundamental.
>
> It's also true that in a lot of usage schenarios, what people actually
> _use_ is "pull" and "push", and no, they aren't mirror images (since push
> will _not_ do the merge), but at the same time, from a _usage_ standpoint
> they really _are_ each others opposites.
The problem is the "usage standpoint" distinction that has to be made.
Exactly because in GIT it is a bit distorted from what most people
expect from other standpoints.
> You "pull" to get other peoples data into your branch (and once you've
> internalized local branches and the merge thing, you know what this
> means), and you "push" to push your changes out. It really _is_ the usage
> schenario, and using "opposite" words really _does_ make sense.
But that's exactly why newbies have problems. Instead of simply
understanding the bare operation (fetch data in a branch _then_ merge
it) they sort of need to abstract the concept of branch away because a
"pull" does it all automagically. Which is fine as long as you're
willing to ignore branch concepts altogether. But once branches are
back in the picture for more involved operations then the "pull" word
simply feels odd. Even more so with the local merge syntax.
When I say to someone "just merge branch weezee with your current
branch" the most intuitive command would be:
git merge weezee
But because "pull" mixes two concepts together this makes the thing more
esoteric. Unless, of course, you get used to the mental model you
outlined above, but IMHO simply needing a mental model to explain the
tool is a sign that something is mapped wrong.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:26 ` Nicolas Pitre
2006-11-15 20:50 ` Linus Torvalds
@ 2006-11-16 1:51 ` Anand Kumria
1 sibling, 0 replies; 601+ messages in thread
From: Anand Kumria @ 2006-11-16 1:51 UTC (permalink / raw)
To: git
On Wed, 15 Nov 2006 15:26:44 -0500, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Petr Baudis wrote:
>
>> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
>> > You have to admit both pull and fetch have been contaminated
>> > with loaded meanings from different backgrounds. I was talking
>> > about killing the source of confusion in the longer term by
>> > removing fetch/pull/push, so we are still on the same page.
>>
>> How was/is fetch contaminated?
>
> I think "fetch" is sane. Its only problem is a missing symetrical
> counterpart verb, like "get" and "put".
"throw" ?
But I think "I'll just 'throw' this set of patches at you" is a lot
harshers sounding than "I'll just 'push' this set of patches at you".
Anand
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 21:10 ` Carl Worth
2006-11-14 21:30 ` Jakub Narebski
@ 2006-11-14 22:36 ` Junio C Hamano
2006-11-14 22:50 ` Junio C Hamano
` (2 more replies)
1 sibling, 3 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:36 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Andy Whitcroft, Nicolas Pitre
Carl Worth <cworth@cworth.org> writes:
> On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
>> Even if I have a clear preference for GIT's _technology_, I still think
>> that the HG user interface is more convivial. I even been thinking
>> about writing something like an hg-like frontend to GIT from time to
>> time just so that GIT could then be better compared to (and actually
>> just used like) HG.
>
> I've actually been tempted to do the same myself. I really think that
> the technology is a more important criterion than the UI so the
> imagined hg-on-git interface would be an attempt to get people to look
> past the interface differences and look at the technology when
> deciding.
>...
>> I still think that the GIT user interface sucks in many ways. The
>...
I've actually been tempted to do that too, and my earlier "if I
were to redo git from scratch" message was the beginning of it
to summarize my preference about some of the issues raised in
this thread.
Commenting on the messages in this thread:
- "resolve / resolved" are both confusing, when you are talking
about "mark-resolved" operation.
- "pull/push/fetch" have undesired confusion depending on where
people learned the term. I'd perhaps vote for replacing
fetch with download and push with upload.
- I think it would be sensible to make remote tracking branches
less visible. For example:
git diff origin
where origin is the shorthand for your upstream (e.g. you
have .git/remotes/origin that records the URL and the branch
you are tracking) should be easier to understand than
git diff remotes/origin/HEAD
The latter is an implementation detail. I could imagine we
might even want to allow
git diff origin#next
to name the branch of the remote repository. The notion of
"where the tips of remote repository's branches are" is
probably be updated by "git download" (in other words, the
above "git diff" does not automatically initiate network
transfer).
- "git merge" to merge another branch into the current would
make sense. "git pull . remotes/origin/next" is showing too
much implementation detail. It should just be:
git merge origin#next
And I agree with Pasky that fixing UI is hard unless you are
willing to get rid of historical warts. Syntax of the command
line arguments the current set of Porcelain-ish takes are
sometimes just horrible. It may not be a bad idea to start
building the fixed UI from scratch, using different prefix than
"git" (say "gu" that stands for "git UI" or "gh" that stands for
"git for humans").
Of course, it could even be "cg" ;-).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:36 ` Junio C Hamano
@ 2006-11-14 22:50 ` Junio C Hamano
2006-11-15 4:32 ` Nicolas Pitre
2006-11-16 5:12 ` Petr Baudis
2006-11-18 7:59 ` Alan Chandler
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 22:50 UTC (permalink / raw)
To: git, Andy Whitcroft, Nicolas Pitre, Carl Worth
Junio C Hamano <junkio@cox.net> writes:
> - I think it would be sensible to make remote tracking branches
> less visible. For example:
>...
> - "git merge" to merge another branch into the current would
> make sense. "git pull . remotes/origin/next" is showing too
> much implementation detail. It should just be:
>
> git merge origin#next
This and other examples in "making remote tracking branches less
visible" are hard to read because I used the word "origin" in
two different sense. So here is a needed clarification.
If you have remotes/upstream that says:
URL: git://git.xz/repo.git
Pull: refs/heads/master:remotes/origin/master
Pull: refs/heads/next:remotes/origin/next
Then, currently the users need to say:
git diff remotes/origin/master
git merge remotes/origin/next
By "making tracking branches less visible", what I mean is to
let the users say this instead:
git diff upstream
git merge upstream#next
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:50 ` Junio C Hamano
@ 2006-11-15 4:32 ` Nicolas Pitre
2006-11-15 5:35 ` Junio C Hamano
` (3 more replies)
0 siblings, 4 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft, Carl Worth
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > - I think it would be sensible to make remote tracking branches
> > less visible. For example:
> >...
> > - "git merge" to merge another branch into the current would
> > make sense. "git pull . remotes/origin/next" is showing too
> > much implementation detail. It should just be:
> >
> > git merge origin#next
>
> This and other examples in "making remote tracking branches less
> visible" are hard to read because I used the word "origin" in
> two different sense. So here is a needed clarification.
>
> If you have remotes/upstream that says:
>
> URL: git://git.xz/repo.git
> Pull: refs/heads/master:remotes/origin/master
> Pull: refs/heads/next:remotes/origin/next
>
> Then, currently the users need to say:
>
> git diff remotes/origin/master
> git merge remotes/origin/next
>
> By "making tracking branches less visible", what I mean is to
> let the users say this instead:
>
> git diff upstream
> git merge upstream#next
What is the point of hiding tracking branches? Why just not making them
easier to use instead? There are currently so many ways to specify
remote branches that even I get confused.
OK..... let's pretend this is my follow-up to your "If I were redoing
git from scratch" query. Actually I would not redo it from scratch
since the vast majority of it is rather sane already. But here's some
changes that I would do:
1) make "git init" an alias for "git init-db".
What's the point of "-db"? Sure we're initializing the GIT database.
But who cares? The user doesn't care if GIT uses a "database" or
whatever. And according to some people's definition of a "database" it
could be argued that GIT doesn't use a database at all in the purist
sense of it. What the user wants is to get started and "init" (without
the "-db" is so much more to the point. Doesn't matter if incidentally
it happens to be the same keyword HG uses for the same operation because
we are not afflicted by the NIH disease, right? And it has 3 chars less
to type which is for sure a premium improvement to the very first GIT
user experience!
2) "pull" and "push" should be symmetrical operations
They are symmetrical in the dictionary and in people's mind. OK but what
if I merge content from another _local_ branch into the current one?
Isn't that kind of a pull as well? Answer: NO IT IS NOT! Reason:
because we already have "merge" for that very operation for damn sake!
And because "merging" isn't a synonym for "pulling" at all, we cannot
pretend it should sort of become more true if taken the other way
around.
Actually, if we _merge_ stuff together, we certainly have to /pull/ some
of it, meaning that "merge" might imply a "pull", even in real life
situations outside of the GIT context (think merging Vodka and Kahlua in
a glass where you might have to pull the Vodka bottle out of the freezer
before you can merge it). And thankfully we got it right with git-merge
which can take either a branch or an URL as argument which in the later
case will perform a pull implicitly (OK currently a fetch but you know
what I mean).
But trying to put in people's head that "pulling" implies a "merge"? No
that doesn't work really well. OK if you pull too hard on the Vodka
bottle that might imply a merge at some point but it would certainly be
accidental. And it is not without coincidence that some people had
accidental GIT merges by using git-pull.
Conclusion: git-pull must not perform any merge. It is the symmetrical
operation of a push meaning that it pulls content from a remote branch
and does no more. People understands that pretty well, . This makes
git-fetch redundant (or an alias to git-pull) in that case, and again we
don't mind it becoming similar to in HG because we admit HG was right
about it.
3) remote branch handling should become more straight forward.
OK! Now that we've solved the pull issue and that everybody agrees with
me (how can't you all agree with me anyway) let's have a look at remote
branches. It should be simple:
a) git-pull git://repo.com/time_machine.git
This pulls every branches from the time_machine.git repository and
create identically named branches locally, except for the remote
master becoming origin locally. All those branches are marked read-only
(i.e. cannot commit to them) and _each_ of those branches get an URL
associated to them somehow (the association is an implementation
detail).
If then you do:
b) git-pull origin
Then it will pull the git://repo.com/time_machine.git:master branch into
the local "origin" branch. IOW, local tracking branches becomes
synonyms for their remote URLs after they've been pulled once. If the
remote branch "next" became a local "next" with the first pull (because
it didn't specify any branch meaning that they were all pulled), doing
a:
c) git-pull next
would actually be the same as:
d) git-pull git://repo.com/time_machine.git:next
Now to have different remote and local names for those tracking
branches:
e) git-pull git://repo.com/time_machine.git:master upstream
would be a variation where a remote branch gets a different local name.
This pulls the remote master branch but calls it "upstream" locally.
If that "upstream" branch does exist locally already then fail with
appropriate error message, unless the local branch happens to have the
same URL attribute already. You then have two local branches tracking
the same remote branch which is weird but still fine if someone wants
to have different views (today's pull and yesterday's pull). This is
not necessarily something to encourage but only a fallout of the branch
semantic. And again a simple:
f) git-pull upstream
would update the "upstream" branch from the remote master branch.
I think the concept of "branch group" should be preserved too. So if
you create a group called "warp", then add "origin", "next", and
"upstream" to it, then:
g) git-pull warp
would pull all the included branches. One way to create a branch group
with the initial pull is not to specify the remote branch but only the
repository URL, like:
h) git-pull git://repo.com/time_machine.git warp
Because no specific branch in the remote repository was specified just
like in (a) then all branches are pulled, but because a local name was
provided then this becomes a branch group.
Branch groups could be used to extend the branch namespace as well to
avoid clashes with different remote repositories. In this case the
branch groups could be a way to arrange branches in a hierarchy so
"warp" refer to all branches included in the warp group while
"warp/upstream" refer to only one branch. In this case "upstream" and
"warp/upstream" would be the same branch if "upstream" was effectively
added to the "warp" group, but it doesn't need to be so. And branches
in a group don't have to come from the same remote repository either
since the source of each branch (the URL) is a per branch attribute.
To make it "easy" on the user, I think that any branch (or tag) down the
hierarchy should be used without the "path" leading to it if there is no
conflict. We already do that with heads and tags, So if for example the
"warp" group contained a branch named "lightspeed" but no such branch
(or tag) existed anywhere else then it could be referenced with simply
"lightspeed" or "warp/lightspeed".
Then you don't need any strange scheme for diff and merge. Just using
"git-diff upstream" or "git-merge origin next" suffice. Oh and I don't
think it would be a good idea to have a completely separate namespace
for local vs remote aka tracking branches. Maybe in .git/refs/ they
should be separate to distinguish which ones are read-only remote
tracking ones and which ones are local, but that must not be forced on
the UI.
Thinking about it some more, maybe (a) should create a default branch
group if the remote repository has more than one branches, say "origin".
This way, git-pull without any argument would be the same as
"git-pull origin" by default. If "origin" is a single branch then
(git-pull" would pull only one branch, but if "origin" is a branch group
then all included branches would be pulled.
This becomes formalized as:
git_pull [<URL>] [<local_name>]
If <URL> includes a branch name then <local_name> is a single branch
name. If <URL> doesn't include any branch name then <local_name>
becomes a local branch group name containing all branches in the remote
repository. If <URL> is specified but not <local_name> then <local_name>
is set to "origin" by default, unless it already exists in which case it
is an error and the pull fails. If <URL> is not specified then the URL
attribute to the specified branch(es) is used. If nothing is specified
then "origin" is used for <local_name> by default and URL attribute of
the origin branch or the origin branch group is/are used.
*****
OK I think this is enough for now. I know that parts of what I've said
can already be found in GIT, but I wanted the explanation to be
complete and therefore tentatively coherent.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:32 ` Nicolas Pitre
@ 2006-11-15 5:35 ` Junio C Hamano
2006-11-15 6:18 ` Shawn Pearce
2006-11-15 14:01 ` Johannes Schindelin
2006-11-15 9:17 ` Andy Parkins
` (2 subsequent siblings)
3 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 5:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Andy Whitcroft, Carl Worth
Nicolas Pitre <nico@cam.org> writes:
> What is the point of hiding tracking branches? Why just not making them
> easier to use instead? There are currently so many ways to specify
> remote branches that even I get confused.
Ok, I think in essence we are saying the same thing except I
went overboard by suggsting to extend sha1_name to also look at
.git/remotes/$name which is not necessary, because we already
have the .git/refs/remotes/%s/HEAD magic there. Consider the
suggestion of "upstream#next" syntax retracted, please.
> 1) make "git init" an alias for "git init-db".
Or even better, have "gh init".
> 2) "pull" and "push" should be symmetrical operations
I think that makes a lot of sense to have "gh pull" and "gh
push" as symmetric operations, and make "gh merge" do the
fast-forward and 3-way merge magic done in the current "git
pull". These three words would have a lot saner meaning.
> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with
> me (how can't you all agree with me anyway) let's have a look at remote
> branches.
I would probably prefer making the default namespace under
.git/refs/remotes/remote-name for the tracking branches this
proposal creates, but other than that I agree with the general
direction this proposal is taking us, including branch groups.
We have .git/refs/remotes/%s/HEAD magic so I do not think we
even need to treat one branch repository any specially as you
suggsted.
The reason I am suggsting "gh" instead of "git" is primarily to
deal with stale documentation people would find googling. I can
easily see people get confused by reading "pull = fetch + merge"
from either mailing list archive or Git cheat sheet various
projects seem to have developed.
It does not mean we need to redo _all_ UI. I think most of the
archaeology commands have sane UI so during the transition
period (git 1.99) we can have "git log" and "gh log" which are
one and the same program, and perhaps git 2.0 can be shipped
with clear distinction between plumbing (i.e. git-update-index
and friends) and porcelain (e.g. "gh pull" that only fetches but
with the user friendliness you outlined here), with backward
compatibility wart to help old timers (e.g. "git pull" that
still does "git fetch" followed by "git merge").
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 5:35 ` Junio C Hamano
@ 2006-11-15 6:18 ` Shawn Pearce
2006-11-15 6:30 ` Junio C Hamano
2006-11-15 14:01 ` Johannes Schindelin
1 sibling, 1 reply; 601+ messages in thread
From: Shawn Pearce @ 2006-11-15 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth
Junio C Hamano <junkio@cox.net> wrote:
> Or even better, have "gh init".
Why gh? Is Git just Mercurial backwards? :)
I'm all in favor of this discussion, and in particular of just
breaking the entire UI in 2.0 by using a new frontend command.
I'm just not sure that "Mercurial backwards" describes Git well.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 6:18 ` Shawn Pearce
@ 2006-11-15 6:30 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 6:30 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Or even better, have "gh init".
>
> Why gh? Is Git just Mercurial backwards? :)
>
> I'm all in favor of this discussion, and in particular of just
> breaking the entire UI in 2.0 by using a new frontend command.
> I'm just not sure that "Mercurial backwards" describes Git well.
I do not have any obsession to any name as long as it is
different from "git" to avoid confusion coming from older
documents that would be found by googling. gh was just
shorthand for "git for humans" (and easy to type with index
fingers). I think I listed a few other possibilities in my
previous message.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 5:35 ` Junio C Hamano
2006-11-15 6:18 ` Shawn Pearce
@ 2006-11-15 14:01 ` Johannes Schindelin
2006-11-15 15:03 ` Sean
2006-11-15 15:10 ` Nicolas Pitre
1 sibling, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2006-11-15 14:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth
Hi,
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > 1) make "git init" an alias for "git init-db".
>
> Or even better, have "gh init".
Please no. It only makes things even more confusing. "git init" is perfect
as it is. We can always have internal aliases from "init-db" to "init" to
account for older usages.
> > 2) "pull" and "push" should be symmetrical operations
>
> I think that makes a lot of sense to have "gh pull" and "gh
> push" as symmetric operations, and make "gh merge" do the
> fast-forward and 3-way merge magic done in the current "git
> pull". These three words would have a lot saner meaning.
I am really opposed to do "gh pull". Not only because of "gh" being
completely confusing (we already _have_ "git", and for porcelains
different TLAs), but "pull" _really_ is confusing by now. And Mercurial
did not help one wit by insisting on their own interpretation.
Why not do something like "get/put" instead? It is
- easier to remember
- not bogus (AFAICT the meaning is not used in diametrical senses)
- shorter to type than download/upload
As for "git merge": Just by the number of arguments you can discern
between the original usage and the new usage, so I am all in favour of
replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>"
can be a branch or a remote or a URL (with cogito style #branchname).
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 14:01 ` Johannes Schindelin
@ 2006-11-15 15:03 ` Sean
2006-11-15 15:10 ` Nicolas Pitre
1 sibling, 0 replies; 601+ messages in thread
From: Sean @ 2006-11-15 15:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Nicolas Pitre, git, Andy Whitcroft, Carl Worth
On Wed, 15 Nov 2006 15:01:47 +0100 (CET)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I am really opposed to do "gh pull". Not only because of "gh" being
> completely confusing (we already _have_ "git", and for porcelains
> different TLAs), but "pull" _really_ is confusing by now. And Mercurial
> did not help one wit by insisting on their own interpretation.
This makes a lot of sense. The "git" command isn't damaged so bad
that it can't be saved in a backward compatible way, at least for
a transition period. Adding a new command name seems like a step
backward.
> Why not do something like "get/put" instead? It is
>
> - easier to remember
> - not bogus (AFAICT the meaning is not used in diametrical senses)
> - shorter to type than download/upload
>
> As for "git merge": Just by the number of arguments you can discern
> between the original usage and the new usage, so I am all in favour of
> replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>"
> can be a branch or a remote or a URL (with cogito style #branchname).
Both these ideas sound like a step in the right direction too.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 14:01 ` Johannes Schindelin
2006-11-15 15:03 ` Sean
@ 2006-11-15 15:10 ` Nicolas Pitre
2006-11-15 18:16 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 15:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth
On Wed, 15 Nov 2006, Johannes Schindelin wrote:
> On Tue, 14 Nov 2006, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@cam.org> writes:
> >
> > > 2) "pull" and "push" should be symmetrical operations
> >
> > I think that makes a lot of sense to have "gh pull" and "gh
> > push" as symmetric operations, and make "gh merge" do the
> > fast-forward and 3-way merge magic done in the current "git
> > pull". These three words would have a lot saner meaning.
>
> I am really opposed to do "gh pull". Not only because of "gh" being
> completely confusing (we already _have_ "git", and for porcelains
> different TLAs), but "pull" _really_ is confusing by now. And Mercurial
> did not help one wit by insisting on their own interpretation.
I completely agree that creating yet another command prefix for
basically the same tools would be a disaster. We have "git" already so
let's stick to it and make its usage just more sane.
> Why not do something like "get/put" instead? It is
>
> - easier to remember
> - not bogus (AFAICT the meaning is not used in diametrical senses)
> - shorter to type than download/upload
Well, of all compromizes this is probably the best one so far. I would
have prefered to bite the bullet and fix "pull" instead of adding yet
more commands. But if the consensus is that there is no way on earth
that "pull" can be salvaged then get/put is probably more enjoyable than
download/upload. This way pull/fetch/push could still be available
(albeit burried somewhere out of sight).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 15:10 ` Nicolas Pitre
@ 2006-11-15 18:16 ` Junio C Hamano
2006-11-15 19:02 ` Andy Parkins
2006-11-16 0:23 ` Han-Wen Nienhuys
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 18:16 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
>> Why not do something like "get/put" instead? It is
>>
>> - easier to remember
>> - not bogus (AFAICT the meaning is not used in diametrical senses)
>> - shorter to type than download/upload
>
> Well, of all compromizes this is probably the best one so far. I would
> have prefered to bite the bullet and fix "pull" instead of adding yet
> more commands. But if the consensus is that there is no way on earth
> that "pull" can be salvaged then get/put is probably more enjoyable than
> download/upload. This way pull/fetch/push could still be available
> (albeit burried somewhere out of sight).
I still think in the long run you would be better off giving
separate names to Porcelains because I am sure you are going to
find the next command to "fix", you cannot suddenly change the
semantics of the command, and you soon run out of alternative
ways to name the action and you in addition have to explain the
differences between fetch and get to new users. At least, with
"ig pull", you can dismiss all the broken git-x Porcelain-ish by
saying "Oh, git-x user-level commands had inconsistent semantics
and broken UI so do not use them anymore -- they are still there
only to help old timers transition. The user level commands are
now called ig-x and ig stands for improved git".
But that's a very minor detail and can be fixed when we hit the
wall, so let's wait and see what happens. Please consider my
gh/gu/cg/whatever dropped.
I think get/put is much better than suddenly changing what pull
means and is shorter to type than x-load; I am Ok with them.
Although I think these words are tainted by SCCS, I do not think
anybody cares.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:16 ` Junio C Hamano
@ 2006-11-15 19:02 ` Andy Parkins
2006-11-15 19:41 ` Junio C Hamano
2006-11-16 0:23 ` Han-Wen Nienhuys
1 sibling, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 19:02 UTC (permalink / raw)
To: git
On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to
The problem I think with that is that the line between plumbing and porcelain
is not clear. If you have two names then for the ambiguous ones you are just
making it more confusing because there is yet another variable to try before
you get the function you want.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:02 ` Andy Parkins
@ 2006-11-15 19:41 ` Junio C Hamano
2006-11-15 20:15 ` Nicolas Pitre
2006-11-15 20:19 ` Carl Worth
0 siblings, 2 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 19:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
>
>> I still think in the long run you would be better off giving
>> separate names to Porcelains because I am sure you are going to
>
> The problem I think with that is that the line between plumbing and porcelain
> is not clear.
This is moot because we (at least tentatively) agreed not to do
"gh" or "ig" or whatever, but I do not understand why you feel
so.
If we had a separate Porcelain namespace (say "ng" for "new
git") you would know "ng-commit" is not a Plumbing and when you
are writing a Porcelain script you would stay away from using it
in your script.
In the longer term, when the new Porcelain UI Nico and friends
are designing matures, and if it makes everybody (including
existing users who learned git-* Porcelain-ish during 18-months
process) happy, we could gradually deprecate and eventually
remove the git-* Porcelain-ish over time, at that point we would
have a very clear line between plumbing and porcelain.
But that would not be a flag-day change. During the transition
period you cannot mechanically tell if git-foo is a plumbing or
a porcelain just like you cannot do so now.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:41 ` Junio C Hamano
@ 2006-11-15 20:15 ` Nicolas Pitre
2006-11-15 20:19 ` Carl Worth
1 sibling, 0 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> If we had a separate Porcelain namespace (say "ng" for "new
> git") you would know "ng-commit" is not a Plumbing and when you
> are writing a Porcelain script you would stay away from using it
> in your script.
There is merit in trying to segregate porcelain vs plumbing... at least
in theory. In practice though I don't think this is something we should
absolutely strive for.
Why? Because something is always going to fail the categorization.
Sure there are commands that are pure plumbing like git-commit-tree,
etc. Some are pure porcelain like git-commit or git-log. Yet we use
git-log's output for git-shortlog. Does it mean that git-log is
plumbing? Also I have a script here that uses git-commit directly
because it is so much convenient rather than futzing with the really
bare plumbing. I don't think git-commit should be prevented from being
used within another script even if it is classified as porcelain.
So we have that notion of plumbing vs porcelain but in practice there is
a whole spectrum between those two poles and I think it is a good thing.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 19:41 ` Junio C Hamano
2006-11-15 20:15 ` Nicolas Pitre
@ 2006-11-15 20:19 ` Carl Worth
2006-11-15 21:13 ` Junio C Hamano
1 sibling, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]
On Wed, 15 Nov 2006 11:41:20 -0800, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
> >
> >> I still think in the long run you would be better off giving
> >> separate names to Porcelains because I am sure you are going to
> >
> > The problem I think with that is that the line between plumbing and porcelain
> > is not clear.
>
> This is moot because we (at least tentatively) agreed not to do
> "gh" or "ig" or whatever, but I do not understand why you feel
> so.
I'm not the original poster, but I feel the same way about the line
being unclear.
Here's a real-world example from last week.
For cairo I wrote a little script that two revspecs, (or one in
which case its first parent is used), and it goes off and checks out
both versions, builds each, runs a performance test on each, and then
generates a report showing the performance impact.
So now I can do things like:
# What's the performance impact of my latest change:
cairo-perf-diff HEAD
# Have my last few changes helped as much as I'd hoped:
cairo-perf-diff HEAD~3 HEAD
# How has performance changed since our last stable release:
cairo-perf-diff 1.2.6 HEAD
Anyway, when I announced this I also mentioned how easily someone
might generate an entire series of reports for a series of
commits. The command I gave as an example is:
for rev in $(git rev-list 1.2.6..HEAD); do
cairo-perf-diff $rev
done
I think that's a perfectly legitimate one-liner for users to use, and
it really shows off the easy-scriptability of git. But certainly, no
"new porcelain" author is going to consider rev-list to be porcelain
rather than plumbing, right? So as soon as I start teaching people to
do useful stuff like this, they might have to reach down into the
"scary" git interface.
I think we're much better off just having one "git" namespace for the
standard command-line interface, and then making it as easy to use as
possible.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 20:19 ` Carl Worth
@ 2006-11-15 21:13 ` Junio C Hamano
2006-11-15 22:36 ` Carl Worth
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 21:13 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Parkins, git
Carl Worth <cworth@cworth.org> writes:
> I'm not the original poster, but I feel the same way about the line
> being unclear.
>
> Here's a real-world example from last week.
>...
> Anyway, when I announced this I also mentioned how easily someone
> might generate an entire series of reports for a series of
> commits. The command I gave as an example is:
>
> for rev in $(git rev-list 1.2.6..HEAD); do
> cairo-perf-diff $rev
> done
>
> I think that's a perfectly legitimate one-liner for users to use, and
> it really shows off the easy-scriptability of git. But certainly, no
> "new porcelain" author is going to consider rev-list to be porcelain
> rather than plumbing, right? So as soon as I start teaching people to
> do useful stuff like this, they might have to reach down into the
> "scary" git interface.
That is a very fine example, but I do not see why it is a
problem. I do not think the goal of Porcelain is to make it
totally unnecessary for users to know about the plumbing.
The one-liner is essentially a new Porcelain command that is
useful in the cairo developers' workflow, and implementing it
with a plumbing command makes perfect sense. The whole point of
git plumbing is to be friendly for scripted use. If the user
who learns that one-liner from you gets curious why and how that
one-liner works, that would be a good gentle introduction to the
plumbing, but otherwise the user is not forced to know about it.
Also I do not see a problem if some plumbing commands happen to
be also useful by themselves ("[alias] less = -p cat-file -p"
comes to mind for example).
Some plumbing commands may be too deep magic and users do not
have to directly deal with them every day. Some other plumbing
commands are so low-level and needs combination with others to
be any useful, and it is cumbersome to type the combination
every day. For the latter kind, we have Porcelain commands that
implement the frequently used combination and the end users do
not have to know about them.
So it is true that by having a rich and usable set of Porcelain,
there is less need for the users to know about all the plumbing
details, but I consider that is a happy consequence. It does
not have to be the goal of having a good Porcelain to hide the
whole plumbing.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 21:13 ` Junio C Hamano
@ 2006-11-15 22:36 ` Carl Worth
2006-11-16 3:21 ` Petr Baudis
0 siblings, 1 reply; 601+ messages in thread
From: Carl Worth @ 2006-11-15 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> That is a very fine example, but I do not see why it is a
> problem. I do not think the goal of Porcelain is to make it
> totally unnecessary for users to know about the plumbing.
If not, then the promise of the porcelain fails. If cogito offers
"Here are 40 commands so you don't have to learn git's 140" and then
next says "Oh, and you'll still want to learn all those git commands
too", then its existence only makes the "too much stuff to learn"
problem worse, not better.
But I think you agree with me (for now) that fixing the git UI should
not involve creating a new primary command to replace "git".
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 22:36 ` Carl Worth
@ 2006-11-16 3:21 ` Petr Baudis
2006-11-16 10:09 ` Robin Rosenberg
0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 3:21 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Andy Parkins, git
On Wed, Nov 15, 2006 at 11:36:21PM CET, Carl Worth wrote:
> On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:
> > That is a very fine example, but I do not see why it is a
> > problem. I do not think the goal of Porcelain is to make it
> > totally unnecessary for users to know about the plumbing.
>
> If not, then the promise of the porcelain fails. If cogito offers
> "Here are 40 commands so you don't have to learn git's 140" and then
> next says "Oh, and you'll still want to learn all those git commands
> too", then its existence only makes the "too much stuff to learn"
> problem worse, not better.
I didn't get this argument before either - why do you need to learn "all
those git commands" too? You'll never have to learn "git add" or even
"git commit". If you want to pick specific git commands later (like "git
bisect", which even seeks in a Cogito-compatible way), that's fine, go
ahead! But you by no means have to learn _other_ commands than those you
need. If you want to bisect, you have to learn no other Git commands
than "git bisect".
Another point is, if using _just_ _git_ requires you to learn "all those
git commands too" from git-commit-tree up (yes it does! if you want your
authorship information to be correct), something is wrong.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 3:21 ` Petr Baudis
@ 2006-11-16 10:09 ` Robin Rosenberg
2006-11-16 13:46 ` Petr Baudis
0 siblings, 1 reply; 601+ messages in thread
From: Robin Rosenberg @ 2006-11-16 10:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git
torsdag 16 november 2006 04:21 skrev Petr Baudis:
> Another point is, if using _just_ _git_ requires you to learn "all those
> git commands too" from git-commit-tree up (yes it does! if you want your
> authorship information to be correct), something is wrong.
When/why do I need git-commit-tree? Isn't git-commit enough?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 10:09 ` Robin Rosenberg
@ 2006-11-16 13:46 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Carl Worth, Junio C Hamano, Andy Parkins, git
On Thu, Nov 16, 2006 at 11:09:13AM CET, Robin Rosenberg wrote:
> torsdag 16 november 2006 04:21 skrev Petr Baudis:
> > Another point is, if using _just_ _git_ requires you to learn "all those
> > git commands too" from git-commit-tree up (yes it does! if you want your
> > authorship information to be correct), something is wrong.
>
> When/why do I need git-commit-tree? Isn't git-commit enough?
As I said, when you need to find out how to setup your authorship
information. It's documented as deep as on the git-commit-tree level.
BTW, the documentation is another important part of the
plumbing/porcelain separation, it's not only about the list of commands
but also that porcelain documentation should be reasonably
self-contained and not require users to peek at plumbing docs in order
to find out many stuff. It's also a consideration I take when
maintaining Cogito documentation.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:16 ` Junio C Hamano
2006-11-15 19:02 ` Andy Parkins
@ 2006-11-16 0:23 ` Han-Wen Nienhuys
1 sibling, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-16 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano escreveu:
> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to
> find the next command to "fix", you cannot suddenly change the
> "ig pull", you can dismiss all the broken git-x Porcelain-ish by
> saying "Oh, git-x user-level commands had inconsistent semantics
> and broken UI so do not use them anymore -- they are still there
> only to help old timers transition. The user level commands are
> now called ig-x and ig stands for improved git".
I think it would be good if there were different commands for
porcelains. Not because fixing the current commands is too much work,
but rather because it would clarify the structure of git. GIT is a
3-layer approach:
- index+workdir+refs over
- a DAG of commits over
- a file based SHA1 database
at first sight it is difficult to tell for each command on which layer
it operates. It would help understanding GIT a lot if each layer got
it's own command, eg.
git - sha1 content db
gic - sequences of commits
giu - UI
(Of course, these names are completely silly, but you get the idea)
> I think get/put is much better than suddenly changing what pull
> means and is shorter to type than x-load; I am Ok with them.
> Although I think these words are tainted by SCCS, I do not think
> anybody cares.
they're also tainted by darcs, but that's a minor problem, I suppose.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:32 ` Nicolas Pitre
2006-11-15 5:35 ` Junio C Hamano
@ 2006-11-15 9:17 ` Andy Parkins
2006-11-15 9:59 ` Jakub Narebski
` (3 more replies)
2006-11-15 12:15 ` Andreas Ericsson
2006-11-16 13:58 ` Petr Baudis
3 siblings, 4 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 9:17 UTC (permalink / raw)
To: git
On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
> OK..... let's pretend this is my follow-up to your "If I were redoing
Personally, I agree with almost everything in this email. Except the
implementation of point 3.
> 3) remote branch handling should become more straight forward.
I was completely confused by this origin/master/clone stuff when I started
with git. In hindsight, now I understand git a bit more, this is what I
would have liked:
* Don't use the name "origin" twice. In fact, don't use it at all. In a
distributed system there is no such thing as a true origin.
* .git/remotes/origin should be ".git/remotes/default". "origin" is only
special because it is the default to push and pull - it's very nice to have a
default, but it should therefore be /called/ "default".
* Whatever git-clone calls the remote, it should be matched by a directory
in .git/refs/remotes. So .git/remotes/$name contains "Pull"s to get all the
remote branches to .git/refs/remotes/$name/*. This implies that
git /always/ does --use-separate-remote in clone. If a branch is practically
read-only it should be technically read-only too.
* If clone really wants to have a non-read-only master, then that should
be .git/refs/heads/master and will initialise
to .git/refs/remotes/$name/master after cloning. Personally I think this is
dangerous because it assumes there is a "master" upstream - which git doesn't
mandate at all. Maybe it would be better to take the upstream HEAD and
create a local branch for /that/ branch rather than require that it is
called "master".
* Ensuring we have /all/ upstream branches at a later date is hard, and not
automatic. Here is the .git/remotes/default file that should be possible:
URL: git://host/project.git
Pull: refs/heads/*:refs/remotes/default/*
Now, every git-pull would check for new upstream branch refs and sync them
into the local remotes list. These are read-only so it'd be perfectly safe
to delete any locally that no longer exist upstream.
* git-clone should really just be a small wrapper around
- git-init-db
- create .git/remotes/default
- maybe create specific .git/config
- git-fetch default
If git-clone does anything that can't be done with settings in the config
and the remotes/default file then it's wrong. The reason I say this is that
as soon as git-clone has special capabilities (like --shared, --local
and --reference) then you are prevented from doing magic with existing
repositories. For example; how do you create a repository that contains
branches from two other local repositories that have the objects hard linked?
While I'm writing wishes, I'd like to jump on Junio's integration with other
fetch-backends wish. I use git-svn, and it would be fantastic if I could
replace:
git-svn init --id upstream/trunk svn://host/path/trunk
git-svn fetch --id upstream/trunk
git-svn init --id upstream/stable svn://host/path/branches/stable
git-svn fetch --id upstream/stable
With a .git/remotes/svn
SVN-URL: svn://host/path
Pull: trunk:refs/remotes/upstream/trunk
Pull: branches/stable:refs/remotes/upstream/stable
and
git fetch svn
Obviously, the syntax is just made up; but you get the idea. Even better,
would be if it could cope with my "*" syntax suggested above:
SVN-URL: svn://host/path
Pull: trunk:refs/remotes/upstream/trunk
Pull: branches/*:refs/remotes/upstream/*
There have been lots of "wishlist" posts lately; would it be useful if I tried
to collect all these suggestions from various people into one place to try
and get a picture of any consensus?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 9:17 ` Andy Parkins
@ 2006-11-15 9:59 ` Jakub Narebski
2006-11-15 10:33 ` Andy Parkins
2006-11-15 15:41 ` Nicolas Pitre
` (2 subsequent siblings)
3 siblings, 1 reply; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 9:59 UTC (permalink / raw)
To: git
Andy Parkins wrote:
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
The remote 'origin' is true origin of the repository: it is repository
we cloned this repository from.
I agree that having branch 'origin', at least in most common multi-branch
(multi-head) repository, is just confusing.
> * Ensuring we have /all/ upstream branches at a later date is hard, and not
> automatic. Here is the .git/remotes/default file that should be possible:
> URL: git://host/project.git
> Pull: refs/heads/*:refs/remotes/default/*
> Now, every git-pull would check for new upstream branch refs and sync them
> into the local remotes list. These are read-only so it'd be perfectly safe
> to delete any locally that no longer exist upstream.
Very nice idea.
> * git-clone should really just be a small wrapper around
> - git-init-db
> - create .git/remotes/default
> - maybe create specific .git/config
I'm not sure about "create .git/remotes/default" part. Isn't git moving from
remotes file to having information about remotes (and branches) in config?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 9:59 ` Jakub Narebski
@ 2006-11-15 10:33 ` Andy Parkins
2006-11-15 10:48 ` Karl Hasselström
0 siblings, 1 reply; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 10:33 UTC (permalink / raw)
To: git
On Wednesday 2006 November 15 09:59, Jakub Narebski wrote:
> > * Don't use the name "origin" twice. In fact, don't use it at all. In
> > a distributed system there is no such thing as a true origin.
>
> The remote 'origin' is true origin of the repository: it is repository
> we cloned this repository from.
But that is not necessarily /the/ original, and "origin" is the absolute
reference in maths. It doesn't bother me that much I suppose, it's just that
as far as unambiguous names go, I'm not wild about it - it's got too
many "central repository" connotations, which is of course anathema to git.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:33 ` Andy Parkins
@ 2006-11-15 10:48 ` Karl Hasselström
2006-11-15 11:28 ` Andy Parkins
0 siblings, 1 reply; 601+ messages in thread
From: Karl Hasselström @ 2006-11-15 10:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On 2006-11-15 11:33:55 +0100, Andy Parkins wrote:
> But that is not necessarily /the/ original, and "origin" is the
> absolute reference in maths. It doesn't bother me that much I
> suppose, it's just that as far as unambiguous names go, I'm not wild
> about it - it's got too many "central repository" connotations,
> which is of course anathema to git.
To me, "origin" just means "where <whatever we're talking about>
originated". If you think of it that way, it's perfectly obvious that
each repository can have its own origin.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 10:48 ` Karl Hasselström
@ 2006-11-15 11:28 ` Andy Parkins
0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 11:28 UTC (permalink / raw)
To: git
On Wednesday 2006 November 15 10:48, Karl Hasselström wrote:
> To me, "origin" just means "where <whatever we're talking about>
> originated". If you think of it that way, it's perfectly obvious that
> each repository can have its own origin.
Of course. I wasn't saying that I didn't understand why origin was chosen.
It's not a completely crazy name - it does have /a/ meaning. However, it's
not an unambiguous meaning. What if the repository I clone was itself a
clone? What if the repository it cloned was pulling from three other
repositories? What if those three repositories pull/push from/to each other?
* -- * -- *
\ | / \
\ | / /
\ | / /
* /
| /
| /
* <--- "origin"
|
* <--- cloned repository
The name "origin" is too close to having an "ultimate source" feel to it IMO.
In a distributed system, it's not the right idea to be pushing. After the
clone is complete, the "origin" is no more special than any other repository,
and if you felt like it you could change the URL for "origin" and it would
make very little difference to you.
In short: I don't think "origin" is wrong, I just think it's not right.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 9:17 ` Andy Parkins
2006-11-15 9:59 ` Jakub Narebski
@ 2006-11-15 15:41 ` Nicolas Pitre
2006-11-15 17:59 ` Junio C Hamano
2006-11-18 11:09 ` Alan Chandler
2006-11-15 17:55 ` Junio C Hamano
2006-11-16 3:53 ` Petr Baudis
3 siblings, 2 replies; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 15:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Wed, 15 Nov 2006, Andy Parkins wrote:
> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
>
> > OK..... let's pretend this is my follow-up to your "If I were redoing
>
> Personally, I agree with almost everything in this email. Except the
> implementation of point 3.
>
> > 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started
> with git. In hindsight, now I understand git a bit more, this is what I
> would have liked:
>
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
I agree, sort of. Not because"origin" is ambigous as a name. But
rather because there is a magic translation from "master" to "origin",
and I think this is wrong to do that.
As mentioned elsewhere (and let's start using "get" instead of "pull" as
suggested by Johannes), a "get" should probably always create a branch
group even if it contains only one branch. This way the remote branch
called "master" will still be called "master" locally, under the branch
group used to represent the remote repository. And if a local name is
not provided then let's just call it "default". This way, amongst the
remote references, there would be a "default/master" that would be used
when nothing else is provided by the user. So...
git get repo.com/time_machine.git
would create a local branch named "remotes/default/master" if the remote
repo has only a master branch.
Then, a simple:
git merge
could be the same as
git merge default
which would be equivalent to
git merge default/master
Afterwards, because the "default" remote already exists, then:
git get
would be the same as
git get default
to get changes for all branches in the "default" remote branches, of
which "master" might be the only one in the simple case.
But again I think it is important that the URL to use must be a per
branch attribute i.e. attached to "default/master" and not just
"default". This way someone could add all branches of interest into the
"default" group even if they're from different repositories, and a
simple get without any argument would get them all.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 15:41 ` Nicolas Pitre
@ 2006-11-15 17:59 ` Junio C Hamano
2006-11-15 18:11 ` Nicolas Pitre
2006-11-18 11:09 ` Alan Chandler
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 17:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
Nicolas Pitre <nico@cam.org> writes:
> But again I think it is important that the URL to use must be a per
> branch attribute i.e. attached to "default/master" and not just
> "default". This way someone could add all branches of interest into the
> "default" group even if they're from different repositories, and a
> simple get without any argument would get them all.
I think the "one group per one remote repository" model is a lot
easier to explain. At least when I read your first "branch
group" proposal that was I thought was going on and I found it
quite sensible (and it maps more or less straightforwardly to
the way existing .git/refs/remotes is set up by default).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 17:59 ` Junio C Hamano
@ 2006-11-15 18:11 ` Nicolas Pitre
2006-11-16 13:21 ` Karl Hasselström
0 siblings, 1 reply; 601+ messages in thread
From: Nicolas Pitre @ 2006-11-15 18:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > But again I think it is important that the URL to use must be a per
> > branch attribute i.e. attached to "default/master" and not just
> > "default". This way someone could add all branches of interest into the
> > "default" group even if they're from different repositories, and a
> > simple get without any argument would get them all.
>
> I think the "one group per one remote repository" model is a lot
> easier to explain. At least when I read your first "branch
> group" proposal that was I thought was going on and I found it
> quite sensible (and it maps more or less straightforwardly to
> the way existing .git/refs/remotes is set up by default).
I think one group per remote repo is how things should be by default
too. But we should not limit it to that if possible.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 18:11 ` Nicolas Pitre
@ 2006-11-16 13:21 ` Karl Hasselström
0 siblings, 0 replies; 601+ messages in thread
From: Karl Hasselström @ 2006-11-16 13:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
On 2006-11-15 13:11:36 -0500, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@cam.org> writes:
> >
> > > But again I think it is important that the URL to use must be a
> > > per branch attribute i.e. attached to "default/master" and not
> > > just "default". This way someone could add all branches of
> > > interest into the "default" group even if they're from different
> > > repositories, and a simple get without any argument would get
> > > them all.
> >
> > I think the "one group per one remote repository" model is a lot
> > easier to explain. At least when I read your first "branch group"
> > proposal that was I thought was going on and I found it quite
> > sensible (and it maps more or less straightforwardly to the way
> > existing .git/refs/remotes is set up by default).
>
> I think one group per remote repo is how things should be by default
> too. But we should not limit it to that if possible.
Without the limitation, we risk name collisions when getting all
branches from the remote repository (that is, including any new
branches we previously didn't know about).
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 15:41 ` Nicolas Pitre
2006-11-15 17:59 ` Junio C Hamano
@ 2006-11-18 11:09 ` Alan Chandler
1 sibling, 0 replies; 601+ messages in thread
From: Alan Chandler @ 2006-11-18 11:09 UTC (permalink / raw)
To: git
On Wednesday 15 November 2006 15:41, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Andy Parkins wrote:
> > * Don't use the name "origin" twice. In fact, don't use it at all. In
> > a distributed system there is no such thing as a true origin.
>
> I agree, sort of. Not because"origin" is ambigous as a name. But
> rather because there is a magic translation from "master" to "origin",
> and I think this is wrong to do that.
>
> As mentioned elsewhere (and let's start using "get" instead of "pull" as
> suggested by Johannes), a "get" should probably always create a branch
> group even if it contains only one branch. This way the remote branch
> called "master" will still be called "master" locally, under the branch
> group used to represent the remote repository. And if a local name is
> not provided then let's just call it "default". This way, amongst the
> remote references, there would be a "default/master" that would be used
> when nothing else is provided by the user. So...
>
> git get repo.com/time_machine.git
>
> would create a local branch named "remotes/default/master" if the remote
> repo has only a master branch.
Why not call it remotes/repo.com/time_machine.git/master and have a
DEFAULT_ORIGIN that is a symref to it in the same way as HEAD is a symref to
a local branch
--
Alan Chandler
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 9:17 ` Andy Parkins
2006-11-15 9:59 ` Jakub Narebski
2006-11-15 15:41 ` Nicolas Pitre
@ 2006-11-15 17:55 ` Junio C Hamano
2006-11-15 19:14 ` Andy Parkins
2006-11-16 3:53 ` Petr Baudis
3 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-15 17:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
>> 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started
> with git. In hindsight, now I understand git a bit more, this is what I
> would have liked:
>
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
>
> * .git/remotes/origin should be ".git/remotes/default". "origin" is only
> special because it is the default to push and pull - it's very nice to have a
> default, but it should therefore be /called/ "default".
I think the naming is just a minor detail and can be overridden
with "clone --origin" already. Renaming it to default is just
like making separate-remote the default to me -- it is fine as
long as it does not break people's expectations.
> * If clone really wants to have a non-read-only master, then that should
> be .git/refs/heads/master and will initialise
> to .git/refs/remotes/$name/master after cloning. Personally I think this is
> dangerous because it assumes there is a "master" upstream - which git doesn't
> mandate at all. Maybe it would be better to take the upstream HEAD and
> create a local branch for /that/ branch rather than require that it is
> called "master".
I think the latter is what clone has done always; take remote's
HEAD and use that to initialize local master (there is no
confusion coming from multiple peer repositories because you
clone from only one place to initialize the repository -- that
one _is_ the origin), and we even keep the HEAD pointing at the
remote's master or whatever it points at at the remote. Using
"$name" as an object name uses .git/refs/remotes/$name/HEAD.
> * git-clone should really just be a small wrapper around
>...
> If git-clone does anything that can't be done with settings in the config
> and the remotes/default file then it's wrong. The reason I say this is that
> as soon as git-clone has special capabilities (like --shared, --local
> and --reference) then you are prevented from doing magic with existing
> repositories.
That is not entirely true. clone has convenience because people
asked. It does not have to mean you are not allowed to give
similar convenience to other commands. Patches?
> branches from two other local repositories that have the objects hard linked?
fetch by second local repository with git-local-fetch perhaps.
> There have been lots of "wishlist" posts lately; would it be
> useful if I tried to collect all these suggestions from
> various people into one place to try and get a picture of any
> consensus?
A list of common things wished by people certainly is a handy
thing to have.
A consensus would not write code and it generally does not take
technology into account to tell what is realistic and what is
not, so the result needs to be take with a grain of salt,
though.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 17:55 ` Junio C Hamano
@ 2006-11-15 19:14 ` Andy Parkins
0 siblings, 0 replies; 601+ messages in thread
From: Andy Parkins @ 2006-11-15 19:14 UTC (permalink / raw)
To: git
On Wednesday 2006, November 15 17:55, Junio C Hamano wrote:
> I think the latter is what clone has done always; take remote's
> HEAD and use that to initialize local master (there is no
It's this sort of thing that is confusing though - the remote HEAD branch
could be anything, and yet that is made to be origin locally as a tracking
branch and then master as the writable branch. What if upstream /has/ a
master but "next" is its HEAD? You'd then get
next:remotes/origin
master:remotes/master
Then a local master which is actually upstream next! Oh dear.
I may well have misunderstood what you've said above above clone always
initialising master from remote's HEAD; if so please disregard what I'm
saying.
> > that as soon as git-clone has special capabilities (like --shared,
> > --local and --reference) then you are prevented from doing magic with
> > existing repositories.
>
> That is not entirely true. clone has convenience because people
> asked. It does not have to mean you are not allowed to give
> similar convenience to other commands. Patches?
Absolutely, that was why I said clone shouldn't have special abilities. In
fact, if you're willing you don't need clone at all; you just need
git-init-db and to write the correct remotes file.
> > branches from two other local repositories that have the objects hard
> > linked?
>
> fetch by second local repository with git-local-fetch perhaps.
Is that not plumbing? I thought this was about porcelain.
> A consensus would not write code and it generally does not take
> technology into account to tell what is realistic and what is
> not, so the result needs to be take with a grain of salt,
> though.
Of course, I only suggested it because the same suggestions were popping up
multiple times. Anyway; I put it in the GitWiki at
http://git.or.cz/gitwiki/Wishlist
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 9:17 ` Andy Parkins
` (2 preceding siblings ...)
2006-11-15 17:55 ` Junio C Hamano
@ 2006-11-16 3:53 ` Petr Baudis
3 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 3:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Wed, Nov 15, 2006 at 10:17:22AM CET, Andy Parkins wrote:
> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
>
> > 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started
> with git. In hindsight, now I understand git a bit more, this is what I
> would have liked:
>
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
>
> * .git/remotes/origin should be ".git/remotes/default". "origin" is only
> special because it is the default to push and pull - it's very nice to have a
> default, but it should therefore be /called/ "default".
But "default" is way too generic a name, it's much more confusing I
think. As the one guilty of inventing master and origin, I agree that
they are somewhat silly, but if I would have to pick which one to
replace with something "better", I'd much rather pick master.
Yes, Git can operate in a completely distributed manner. People do use
it as it. And there are also people that have no origin branch in their
repository. But the vast (overwhelming!) majority of people _does_ work
in some kind of hierarchical setup, and for them origin does have a
meaning. And origin URL can even change over time!
> * git-clone should really just be a small wrapper around
> - git-init-db
> - create .git/remotes/default
> - maybe create specific .git/config
> - git-fetch default
> If git-clone does anything that can't be done with settings in the config
> and the remotes/default file then it's wrong. The reason I say this is that
> as soon as git-clone has special capabilities (like --shared, --local
> and --reference) then you are prevented from doing magic with existing
> repositories. For example; how do you create a repository that contains
> branches from two other local repositories that have the objects hard linked?
Here I think that modulo the lack of remotes support (which is not a
fundamental thing here), the general setup of how Cogito does stuff is
much more saner than the current Git mess. It does basically exactly
what you've said above, and even the fetching itself is IMHO written
much more cleanly than in Git. In an ideal world, Git would just take
Cogito's code here. :-)
> While I'm writing wishes, I'd like to jump on Junio's integration with other
> fetch-backends wish. I use git-svn, and it would be fantastic if I could
> replace:
>
> git-svn init --id upstream/trunk svn://host/path/trunk
> git-svn fetch --id upstream/trunk
> git-svn init --id upstream/stable svn://host/path/branches/stable
> git-svn fetch --id upstream/stable
>
> With a .git/remotes/svn
> SVN-URL: svn://host/path
> Pull: trunk:refs/remotes/upstream/trunk
> Pull: branches/stable:refs/remotes/upstream/stable
> and
> git fetch svn
>
> Obviously, the syntax is just made up; but you get the idea. Even better,
> would be if it could cope with my "*" syntax suggested above:
> SVN-URL: svn://host/path
> Pull: trunk:refs/remotes/upstream/trunk
> Pull: branches/*:refs/remotes/upstream/*
It shouldn't be hard to do at all. Have the porcelain call "protocol
drivers" based on protocol in some generic way, like
/usr/lib/git/protocol/$proto.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:32 ` Nicolas Pitre
2006-11-15 5:35 ` Junio C Hamano
2006-11-15 9:17 ` Andy Parkins
@ 2006-11-15 12:15 ` Andreas Ericsson
2006-11-15 12:31 ` Jakub Narebski
2006-11-16 13:58 ` Petr Baudis
3 siblings, 1 reply; 601+ messages in thread
From: Andreas Ericsson @ 2006-11-15 12:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth
Nicolas Pitre wrote:
[ axed a lot of stuff that I didn't fully grok ]
>
> This becomes formalized as:
>
> git_pull [<URL>] [<local_name>]
>
> If <URL> includes a branch name then <local_name> is a single branch
> name. If <URL> doesn't include any branch name then <local_name>
> becomes a local branch group name containing all branches in the remote
> repository.
I would change that so "local_name" is always a branch group name, but
branch group names can be used as refs. That is,
git pull startrek.com/kirk.git:master kirk
would always create the branch-head .git/refs/remote/kirk/master which
for short can be referenced as just "kirk" (barring clashes ofc), so
long as it only has one branch tracked.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 12:15 ` Andreas Ericsson
@ 2006-11-15 12:31 ` Jakub Narebski
0 siblings, 0 replies; 601+ messages in thread
From: Jakub Narebski @ 2006-11-15 12:31 UTC (permalink / raw)
To: git
Andreas Ericsson wrote:
> Nicolas Pitre wrote:
>
> [ axed a lot of stuff that I didn't fully grok ]
>
>>
>> This becomes formalized as:
>>
>> git_pull [<URL>] [<local_name>]
>>
>> If <URL> includes a branch name then <local_name> is a single branch
>> name. If <URL> doesn't include any branch name then <local_name>
>> becomes a local branch group name containing all branches in the remote
>> repository.
>
> I would change that so "local_name" is always a branch group name, but
> branch group names can be used as refs. That is,
>
> git pull startrek.com/kirk.git:master kirk
I'd rather use Cogito (not gitweb) notation startrek.com/kirk.git#master
This way we can change the name of local branch
startrek.com/kirk.git#master:kirk
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-15 4:32 ` Nicolas Pitre
` (2 preceding siblings ...)
2006-11-15 12:15 ` Andreas Ericsson
@ 2006-11-16 13:58 ` Petr Baudis
3 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth
On Wed, Nov 15, 2006 at 05:32:06AM CET, Nicolas Pitre wrote:
> 1) make "git init" an alias for "git init-db".
>
> What's the point of "-db"? Sure we're initializing the GIT database.
> But who cares? The user doesn't care if GIT uses a "database" or
> whatever. And according to some people's definition of a "database" it
> could be argued that GIT doesn't use a database at all in the purist
> sense of it. What the user wants is to get started and "init" (without
> the "-db" is so much more to the point. Doesn't matter if incidentally
> it happens to be the same keyword HG uses for the same operation because
> we are not afflicted by the NIH disease, right? And it has 3 chars less
> to type which is for sure a premium improvement to the very first GIT
> user experience!
(This is somewhat related to the HEAD issue, e.g.
<7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>, by virtue of basically
eliminating it.)
Let's see. If you are adding the alias, you can as well add some
porcelain stuffing in it, too.
What are the 99% of use cases when doing "init"?
(a) You are going to do an initial commit right away; the repository is
at this point basically useless for anything but initial commit. So you
might have "init" well just perform it for you right away.
(b) You are setting up a bare repository on a server and you will push
to it in a minute. Cogito has a separate cg-admin-setuprepo command for
it, which will also prepare it for usage by dumb servers and optionally
for shared usage in a group of users. Git could have something similar.
> 2) "pull" and "push" should be symmetrical operations
..snip..
> Conclusion: git-pull must not perform any merge. It is the symmetrical
> operation of a push meaning that it pulls content from a remote branch
> and does no more. People understands that pretty well, . This makes
> git-fetch redundant (or an alias to git-pull) in that case, and again we
> don't mind it becoming similar to in HG because we admit HG was right
> about it.
If you _really_ want to do it in Git, the only sensible way to do it is
to stop using the "pull" verb for a command name altogether for at least
some rather long period of time, otherwise that's a blatant backwards
compatibility breakage.
> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with
> me (how can't you all agree with me anyway) let's have a look at remote
> branches. It should be simple:
..snip..
By the way, due to the way you describe it, it's not all that clear to
me how is this (in)compatible with the current way we do it, on other
than the usage and git-pull's auto-creation magic level.
Is it that what you are describing _is_ in fact what we do support now,
with "branch groups" meaning "remotes" etc, and you are only proposing
some enhancements to automatically create remotes in git-pull, or are
there some other differences I've missed?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:36 ` Junio C Hamano
2006-11-14 22:50 ` Junio C Hamano
@ 2006-11-16 5:12 ` Petr Baudis
2006-11-16 10:45 ` Junio C Hamano
` (2 more replies)
2006-11-18 7:59 ` Alan Chandler
2 siblings, 3 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 5:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
On Tue, Nov 14, 2006 at 11:36:19PM CET, Junio C Hamano wrote:
> Commenting on the messages in this thread:
>
> - "resolve / resolved" are both confusing, when you are talking
> about "mark-resolved" operation.
Well that's what "resolved" is saying. But speaking of which, it took me
_weeks_ of regular (though not extensive) usage to train my fingers to
write "stg resolved" and not "stg resolve".
> - "pull/push/fetch" have undesired confusion depending on where
> people learned the term. I'd perhaps vote for replacing
> fetch with download and push with upload.
It's too long. :-(
I think if some people have a real problem with something it's "pull",
not push or fetch. Without "pull" name, there's no confusion about
merging or not merging; and without it, there's also no confusion about
"push" and the fetch/push duality. I'm not saying that this is enough an
argument to ditch pull from Git at this point.
> - I think it would be sensible to make remote tracking branches
> less visible. For example:
>
> git diff origin
>
> where origin is the shorthand for your upstream (e.g. you
> have .git/remotes/origin that records the URL and the branch
> you are tracking) should be easier to understand than
>
> git diff remotes/origin/HEAD
>
> The latter is an implementation detail.
Hmm, wait. I didn't start using refs/remotes/ yet for obvious reasons,
but wasn't it generally agreed when implementing them that what you
wrote above would work? (That a ref not found in refs/{heads,tags}/ is
looked up in remotes and if it's a directory, /HEAD is appended.) So it
doesn't for some reason?
> I could imagine we might even want to allow
>
> git diff origin#next
>
> to name the branch of the remote repository. The notion of
> "where the tips of remote repository's branches are" is
> probably be updated by "git download" (in other words, the
> above "git diff" does not automatically initiate network
> transfer).
Yes, that little syntax extension would be cute to have.
> Of course, it could even be "cg" ;-).
So, here is an arbitrary list of random reasons why cg commands are not
part of git yet:
(i) Naming issues. Example: "pull" vs. "update".
(ii) Namespace issues. Big selling point of Cogito is that it's
_simple_. A very important part of that is that your command set is
limited, so that even someone who wants to fully grok Cogito is not
overwhelmed and has just few commands in front of him. I think we're
doing pretty good here, and I very carefully weight adding another
command to the set (I'm actually pondering removing some now). The
similar applies to actual commands' usage, though certainly not so
heavily; and there are few warts here.
But overally, I think this point is pretty much unsolvable and this is
where I actually think the main "incompatibleness" of Cogito and Git
with its free mix of high- and mid- and low- level commands lies. I
don't think the thread provided any solution to this either.
(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted
local changes in your repository when doing stuff. It didn't shine at it
before recent improvements (post-v0.18), but it tried to preserve your
local uncommitted changes during various operations (merging,
fast-forwarding, switching branches, seeking, ...). I think historically
Git's stance to this was negative (it'd rather block the operation), I'm
not sure what the current situation is, though.
(iii) Output format issues. Example: "status" in Git and Cogito
has a completely different format in both. I'm a die-hard fan of
Cogito's format but there're surely die-hard fans of Git's.
(iv) Control issues. I'm reluctant to give up a final word on how the UI
looks like, mostly for the reason of enforcing (ii) and proper
documentation. But this is not a blocker point.
(v) Library issues. Cogito has a pretty neat shell library which it
prices; but that could be carried around. Also, Cogito requires
/bin/bash, but mostly for performance reasons (using builtins instead of
forking for external commands at some points); Git has the advantage of
simply putting that part in C, which is though something I should've
been doing more frequently too.
(vi) Coding issues. This is probably very subjective, but a blocker for
me. I have no issues about C here, but about the shell part of Git.
Well, how to say it... It's just fundamentally incompatible with me. I
*could* do things in/with it, but it's certainly something I wouldn't
_enjoy_ doing _at all_, on a deep level. I think the current shell code
is really hard to read, the ancient constructs are frequently strange at
best, etc. It's surely fine code at functional level and there'll be
people who hate _my_ style of coding and my shell code which isn't
perfect either, but it's just how it is with me.
Now, it would be absolutely awesome if we could start to bridge at least
some of these points, shuffle some functionality around and overally
reduce the code duplication, increase features count and improve general
level of world happiness.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 5:12 ` Petr Baudis
@ 2006-11-16 10:45 ` Junio C Hamano
2006-11-16 13:43 ` Petr Baudis
2006-11-16 21:49 ` Junio C Hamano
2006-11-17 0:11 ` Han-Wen Nienhuys
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 10:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
Petr Baudis <pasky@suse.cz> writes:
> (v) Library issues...
> Git has the advantage of
> simply putting that part in C, which is though something I should've
> been doing more frequently too.
It should be stressed that git-core plumbing written in C is not
just for git Porcelain-ish, and it will continue to be shared
service. We would add core support for what Porcelains need and
we would try hard to keep them generic enough so that other
Porcelains can use them. Keeping the core and Porcelain-ish in
the same project has made it easier to keep them in sync and to
find and add missing features that would benefit Porcelains (not
limited to git Porcelain-ish). But that should not be mistaken
as plumbing somehow belongs more to git Porcelain-ish than to
Cogito or others.
I also think you should take credit for some core improvements
you did yourself (e.g "ls-files -t" format was originally added
for the sole purpose of helping Cogito, but now others use it,
too).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 10:45 ` Junio C Hamano
@ 2006-11-16 13:43 ` Petr Baudis
0 siblings, 0 replies; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
On Thu, Nov 16, 2006 at 11:45:46AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > (v) Library issues...
> > Git has the advantage of
> > simply putting that part in C, which is though something I should've
> > been doing more frequently too.
>
> It should be stressed that git-core plumbing written in C is not
> just for git Porcelain-ish, and it will continue to be shared
> service. We would add core support for what Porcelains need and
> we would try hard to keep them generic enough so that other
> Porcelains can use them. Keeping the core and Porcelain-ish in
> the same project has made it easier to keep them in sync and to
> find and add missing features that would benefit Porcelains (not
> limited to git Porcelain-ish). But that should not be mistaken
> as plumbing somehow belongs more to git Porcelain-ish than to
> Cogito or others.
Of course, I didn't mean to say that. I should do more often things
like adding --stdin to the fetchers. From one part, I'm used to work
with a fixed set of system tools and extending Git with the
functionality I want means changing my thinking mode and "jumping out of
the system" a bit. The other part is that I cannot use the improvements
in Cogito right away (at least not in the main branch) but I have to
wait for the next Git release; but this is mostly just an excuse. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 5:12 ` Petr Baudis
2006-11-16 10:45 ` Junio C Hamano
@ 2006-11-16 21:49 ` Junio C Hamano
2006-11-16 22:20 ` Petr Baudis
2006-11-17 0:11 ` Han-Wen Nienhuys
2 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2006-11-16 21:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
Petr Baudis <pasky@suse.cz> writes:
> (vi) Coding issues. This is probably very subjective, but a blocker for
> me. I have no issues about C here, but about the shell part of Git.
> Well, how to say it... It's just fundamentally incompatible with me. I
> *could* do things in/with it, but it's certainly something I wouldn't
> _enjoy_ doing _at all_, on a deep level. I think the current shell code
> is really hard to read, the ancient constructs are frequently strange at
> best, etc. It's surely fine code at functional level and there'll be
> people who hate _my_ style of coding and my shell code which isn't
> perfect either, but it's just how it is with me.
I've been thinking about revamping the style of shell scripts in
git-core Porcelain-ish for some time, and I have a feeling that
now may be a good time to do so, after one feature release is
out and the list is discussing UI improvements.
But before mentioning the specifics, let me mention one tangent.
I recently installed an OpenBSD bochs (it was actually a qemu
image) without knowing much about the way of the land, and after
adjusting myself to necessary glitches (like "make" being called
"gmake" there), I saw git properly built and pass its selftest.
I was pleasantly surprised when I noticed there was no 'bash' on
the system after all that.
I would like to keep it that way.
I'll list things I would want to and not want to change.
Comments from the list are very appreciated. You can say things
in two ways:
* I guarantee that the _default_ shell on all sane platforms we
care about handle this construct correctly, although it was
not in the original Bourne. There is no reason to stay away
from it these days.
or
* You've stayed away from this construct but now you say you
feel it is Ok to use it. Don't. It would break with the
shell on my platform (or "it is a bad practice because of
such and such reasons").
I do not think many people can say the former with authority
unless you have a portability lab (the company I work for used
to be like that and it was an interesting experience to learn
all about irritating implementation differences). And "POSIX
says shell should behave that way" is _not_ what I want to hear
about.
But the latter should be a lot easier to say, and would be
appreciated because it would help us avoid regressions.
Things I would want to change:
- One indent level is one tab and the tab-width is eight
columns. Some of our scripts tend to use less than eight
spaces for indentation to avoid line wrapping.
- More use of shell functions are fine. Especially if the
above change makes lines too long, the logic should be
refactored.
- It is so 80-ish to follow certain portability and performance
wisdom. The following should go:
. Use "case" when you do not have to use "if test".
. Avoid ${parameter##word} and friends and use `expr` instead
to pick a string apart.
. Avoid "export name=word", write "name=word; export name"
instead.
. Avoid ${parameter:-word} and friends when ${parameter-word}
would do.
Things I do not want to change:
- The shell scripts should start with #!/bin/sh, not
#!/bin/bash (nor even worse "#!/usr/bin/env sh").
- Shell functions are written as "name () { ... }" without
"function" noiseword.
- 'foo && bar || exit' exits with the error code of what
failed; no need to say 'exit $?'.
- String equality check for "test" is a single =, not ==.
- Do not use locals.
- Do not use shell arrays.
- In general, if something does not behave the same way in ksh,
bash and dash, don't use it (that does not mean these three
are special; it just means if something is not even portable
across these three, it is a definite no-no).
I do not think I need to list other common-sense shell idioms in
the latter category (e.g. 'using "test z$name = zexpected" when
we do not know what $name contains' falls into that).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 21:49 ` Junio C Hamano
@ 2006-11-16 22:20 ` Petr Baudis
2006-11-17 1:49 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Petr Baudis @ 2006-11-16 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
On Thu, Nov 16, 2006 at 10:49:36PM CET, Junio C Hamano wrote:
> I would like to keep it that way.
I agree - I certainly don't want to infect Git with bash dependency.
> And "POSIX says shell should behave that way" is _not_ what I want to
> hear about.
Actually, which sane platforms we care about have /bin/sh that is NOT
POSIX compatible?
> Things I would want to change:
What about [ instead of test? And
if foo; then
instead of
if foo
then
?
Am I the only one who hates
case "$log_given" in
tt*)
die "Only one of -c/-C/-F can be used." ;;
*tm*|*mt*)
die "Option -m cannot be combined with -c/-C/-F." ;;
esac
instead of having this stuff in explicit variables and writing out some
explicit boolean expressions? (There _are_ few cases where the case is
cool, but they are rare.)
It would be really great if Git would have something alike the Cogito's
optparse infrastructure. I'm not sure if you can implement it in Bourne
sh with reasonable performance, though...
I think addressing these three particular points would make the scripts
hugely more coder-friendly. (And well, I usually say that coding style
is not *that* important and is frequently overemphasised. But that holds
only to a certain point. ;-)
> Things I do not want to change:
..snip all those I agree with..
> - Do not use locals.
It's a pity. :-( Which shell doesn't support them?
It's not that huge a deal, though.
> - Do not use shell arrays.
This is quite a larger deal, I think; but the portability concerns are
very real, I guess. :|
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 22:20 ` Petr Baudis
@ 2006-11-17 1:49 ` Junio C Hamano
0 siblings, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-17 1:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
Petr Baudis <pasky@suse.cz> writes:
You already said this kind of details are subjective so I'd omit
the usual "I would think" and answer them without worrying about
a big style flamewar. People, please be civil ;-).
> What about [ instead of test?
[ ] is not more readable.
> if foo; then
>
> instead of
>
> if foo
> then
Having "then" on the beginning of line is much more readable.
> Am I the only one who hates
>
> case "$log_given" in
> tt*)
> die "Only one of -c/-C/-F can be used." ;;
> *tm*|*mt*)
> die "Option -m cannot be combined with -c/-C/-F." ;;
> esac
This is much more readable without "case". "abandon the old
rule that told us to avoid if when case would do" applies.
Although it is about multiple possibility switch (so a case can
be made that "case" is appropriate here), we should reduce the
use of "case" to cases like the outermost big "case" you find in
git-merge-one-file-script.
> It would be really great if Git would have something alike the Cogito's
> optparse infrastructure. I'm not sure if you can implement it in Bourne
> sh with reasonable performance, though...
getopt(1) is fine, unless somebody screams that it is not
available on his platform.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-16 5:12 ` Petr Baudis
2006-11-16 10:45 ` Junio C Hamano
2006-11-16 21:49 ` Junio C Hamano
@ 2006-11-17 0:11 ` Han-Wen Nienhuys
2 siblings, 0 replies; 601+ messages in thread
From: Han-Wen Nienhuys @ 2006-11-17 0:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git, Andy Whitcroft, Nicolas Pitre
Petr Baudis escreveu:
> (vi) Coding issues. This is probably very subjective, but a blocker for
> me. I have no issues about C here, but about the shell part of Git.
> Well, how to say it... It's just fundamentally incompatible with me. I
(on a tangent)
I concur, but probably in a different way.
some 10 years ago I vowed never to write perl code again, and some 5
years ago, I made the same pledge for shell scripts, because I spent
inordinate amounts of time debugging them.
When I see the GIT shell scripts, my hands start to itch to make a
nice object oriented Python wrapper for it.
--
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Cleaning up git user-interface warts
2006-11-14 22:36 ` Junio C Hamano
2006-11-14 22:50 ` Junio C Hamano
2006-11-16 5:12 ` Petr Baudis
@ 2006-11-18 7:59 ` Alan Chandler
2 siblings, 0 replies; 601+ messages in thread
From: Alan Chandler @ 2006-11-18 7:59 UTC (permalink / raw)
To: git
On Tuesday 14 November 2006 22:36, Junio C Hamano wrote:
...
>
> And I agree with Pasky that fixing UI is hard unless you are
> willing to get rid of historical warts. Syntax of the command
> line arguments the current set of Porcelain-ish takes are
> sometimes just horrible. It may not be a bad idea to start
> building the fixed UI from scratch, using different prefix than
> "git" (say "gu" that stands for "git UI" or "gh" that stands for
> "git for humans").
>
> Of course, it could even be "cg" ;-).
I have been away on business last week and have been following this thread
from the archives. There is a comment I want to make about split of
Porcelain and Plumbing namespaces that is not particularly an answer to this
particular post, but it does seem an appropriate place to insert it.
I think there were three (historic) mistakes in the development of git
- to split git and cogito so that some of the commands started git and some
cg (aided and abetted by putting them in separate repositories).
- to try and make the distinction between plumbing and porcelein a line in
the sand (after all this is exactly why git and cg separated) when in
practice it isn't that straight forward
- for cogito to (initially) not support the internal branches, but in fact
deal with them via cloned repositories
On the other hand, it was a good move to bring gitk and gitweb into the core
repository.
These were not technical mistakes, but social ones.
Much of the discussion on UI warts doesn't exist in the cogito world (not that
I use it at all anymore, despite its more user friendly interface - just
because I didn't want to learn two parallel sets of commands and I prefered
git's branch model so stuck with the slightly less friendly git command set)
but if you look at any of the SCM comparison discussions that happen now,
they are always comparing the core git with the other SCM, not git plus all
its porcelains.
So I think it would be a mistake (which hopefully does seem to be the
concensus reached in the list) to try and introduce new namespaces to the
command set.
--
Alan Chandler
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
2006-11-14 18:55 ` Andy Whitcroft
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
@ 2006-11-14 23:30 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Junio C Hamano @ 2006-11-14 23:30 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git, Carl Worth
Andy Whitcroft <apw@shadowen.org> writes:
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
I think status should be taken as Porcelain-ish so it should
notice more about the environment to see why the user has
changed but not updated files and recommend the possible action
depending on the context.
For that, you would need to enumerate what kind of 'context'
there could be with the current set of tools. Here is a
strawman.
1. None of the below.
2. A merge was attempted and resulted in a conflict.
3. An am or rebase without --merge was attempted and
resulted in a conflict or patch rejection.
4. A "rebase --merge was attempted and resulted in a conflict.
In the normal case, the next user action would be:
1-1. The user wants that change in the next commit, and should
run "git update-index $that_path" to prepare the index for
partial commit, or "git commit -a" to commit all the
changes made to the working tree so far. Carl's patch
helps the user in this case.
1-2. The user realizes that the some of the changes in the
working tree were not desirable, and "git checkout --
$that_path" to revert them before continuing. Before
deciding to revert, the user may want to check what the
difference is by running "git diff -- $that_path" so
suggesting these two might also be helpful.
1-3. The user wants to keep that change a strictly local change
in the working tree (this is often very useful and making
"commit -a" the default will not be acceptable unless
there is a very compelling reason to do so). This means
the suggestion we would make should clearly be
_suggestion_.
The earlier wording was bad in that it suggested to use a
Plumbing command update-index, but was attempting to convey that
it was merely a conditional suggestion by saying "use it TO MARK
FOR COMMIT", implying that if the user does not want to mark
them for commit, it is Ok not to use update-index.
When a merge is in progress, we would have .git/MERGE_HEAD and
that would be the way to tell case 2. In that case, the next
user action would be:
2-1. The user resolves conflicts and marks them as resolved,
with update-index (or "git mark-resolved"), to prepare the
index for the merge commit. But this is not done for
"Changed but not updated" files but "unmerged" files. We
should strongly suggest not to do _anything_ to "Changed
but not updated" files here.
2-2. The user decides this conflict is too much to handle right
now, and abandones the change by "git reset --hard". This
would lose the local changes ("Changed but not updated"),
so we should suggest to save the change before doing so.
If you are going to abandone this merge with "reset
--hard", your changes to these files will be lost. You
can save them with "git diff HEAD -- $this_path
$that_path..."
which is probably too long for that part of the output but
that is what we would want to say if we want to be
helpful.
When either rebase without --merge or am is in progress, there
would be .dotest/ directory (whose name could be changed but I
think this was a mistake and we would be better off using fixed
names for this kind of application) for git-status to notice.
The next user action would be:
3-1. The user resolves the conflict or manually apply the
patch, update-index the paths involved and proceeds with
"rebase --continue" or "am --resolved". "Changed but not
updated" paths should not be touched in this case,
similarly to 2-1.
3-2. The user gives up. Same as 2-2.
Designing for the "rebase --merge" case and coming up with other
cases are left as exercise to the list for further discussion.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Git 1.0 Synopis (Draft v2)
@ 2005-07-27 10:01 Ryan Anderson
2005-07-27 22:13 ` Junio C Hamano
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
0 siblings, 2 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-27 10:01 UTC (permalink / raw)
To: git
[This is still a draft, but I think I incorporated the suggestons from
the last attempt.]
Source Code Management with Git
Git, sometimes called "global information tracker", is a "directory
content manager". Git has been designed to handle absolutely massive
projects with speed and efficiency, and the release of the 2.6.12 and
(soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
Git uses the SHA1 hash algorithm to provide a content-addressable pseudo
filesystem, complete with its own version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o A collection of related projects are building on the core Git project,
either to provide an easier to use interface on top (StGit, Cogito, qgit,
gitk, gitweb), or to take some of the underlying concepts and reimplement
them directly into another system (Arch 2.0, Darcs-git).
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves spaced and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of Git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Deb packages at:
<insert url here>
Or via Git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
(rsync is generally faster for an initial pull)
Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
Git development takes place on the Git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
Git results from the inspiration and frustration of Linus Torvalds, and
the enthusiastic help of over 300 participants on the development
mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
1 - Generated with the following, in a maildir folder:
find . -type f | xargs grep -h "^From:" | perl -ne \
'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v2)
2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
@ 2005-07-27 22:13 ` Junio C Hamano
2005-07-29 8:27 ` Ryan Anderson
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-07-27 22:13 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan Anderson <ryan@michonline.com> writes:
> Source Code Management with Git
Thanks for doing this. Generally looks excellent.
> o Two, interchangeable, on-disk formats are used:
> o An efficient, packed format that saves spaced and network
> bandwidth.
??? "spaced" ???
> Or via Git itself:
> git clone http://www.kernel.org/pub/scm/git/git.git/
> git clone rsync://rsync.kernel.org/pub/scm/git/git.git/
> (rsync is generally faster for an initial pull)
These need a target directory name to create, like this:
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ $new_dir
git clone http://www.kernel.org/pub/scm/git/git.git/ $new_dir
> Git results from the inspiration and frustration of Linus Torvalds, and
> the enthusiastic help of over 300 participants on the development
> mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
Please drop the e-mail address here; you mention nobody else's.
Well, dropping "the current maintainer" information altogether
might be even better; the above to a casual reader sounds like
Linus was frustrated and I wrote it for him, which is definitely
not what we would like to say. I suspect it still has more code
by Linus than anybody else (I stopped counting some time ago).
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v2)
2005-07-27 22:13 ` Junio C Hamano
@ 2005-07-29 8:27 ` Ryan Anderson
0 siblings, 0 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-29 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Jul 27, 2005 at 03:13:18PM -0700, Junio C Hamano wrote:
> > Git results from the inspiration and frustration of Linus Torvalds, and
> > the enthusiastic help of over 300 participants on the development
> > mailing list.[1] It is maintained by Junio C Hamano <junkio@cox.net>.
>
> Please drop the e-mail address here; you mention nobody else's.
>
> Well, dropping "the current maintainer" information altogether
> might be even better; the above to a casual reader sounds like
> Linus was frustrated and I wrote it for him, which is definitely
> not what we would like to say. I suspect it still has more code
> by Linus than anybody else (I stopped counting some time ago).
Ok. I was thinking I could add "current" into that description. Or,
something like, "Linus has since returned his focus to the kernel, and
passed maintainership to ...".
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Git 1.0 Synopis (Draft v3
2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
2005-07-27 22:13 ` Junio C Hamano
@ 2005-07-29 8:29 ` Ryan Anderson
2005-07-29 10:58 ` Johannes Schindelin
` (2 more replies)
1 sibling, 3 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-07-29 8:29 UTC (permalink / raw)
To: git
Source Code Management with Git
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
Git is a "directory content manager". Git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
Git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o The core Git project considers itself to provide "plumbing" for other
projects, as well as to serve to arbitrate for compatibility between them.
The project built on top of the core Git are referred to as "porcelain".
StGit, Cogito, qgit, gitk and gitweb are all building upon the core Git
tools, and providing an easy to use interface to various pieces of
functionality.
o Some other projects have taken the concepts from the core Git project, and
are either porting an existing toolset to use the Git tools, or
reimplementing the concepts internally, to benefit from the performance
improvements. This includes both Arch 2.0, and Darcs-git.
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves space and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of Git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Deb packages at:
<insert url here>
Or via Git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
(rsync is generally faster for an initial clone, you can switch later
by editing .git/branches/origin and changing the url)
To get the 'Porcelain' tools mentioned above:
SCM Interface layers:
cogito - http://www.kernel.org/pub/software/scm/cogito/
StGIT - http://www.procode.org/stgit/
History Visualization:
gitk - http://ozlabs.org/~paulus/gitk/
gitweb - http://www.kernel.org/pub/software/scm/gitweb/
qgit - http://sourceforge.net/projects/qgit
Git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's Git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
Git development takes place on the Git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v3
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
@ 2005-07-29 10:58 ` Johannes Schindelin
2005-07-29 21:26 ` Sam Ravnborg
2005-07-31 22:15 ` Horst von Brand
2 siblings, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-07-29 10:58 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
I like it!
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v3
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
2005-07-29 10:58 ` Johannes Schindelin
@ 2005-07-29 21:26 ` Sam Ravnborg
2005-07-31 22:18 ` Horst von Brand
2005-07-31 22:15 ` Horst von Brand
2 siblings, 1 reply; 601+ messages in thread
From: Sam Ravnborg @ 2005-07-29 21:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> Source Code Management with Git
....
The article should include a HOWTO part alos. So people can see how to
edit a file, pull from a remote repository etc.
Since you have introduced core and porcelains it would be most logical
to use one of the porcelains in these examples, maybe accompanied by the
raw git commands being executed.
Sam
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v3
2005-07-29 21:26 ` Sam Ravnborg
@ 2005-07-31 22:18 ` Horst von Brand
0 siblings, 0 replies; 601+ messages in thread
From: Horst von Brand @ 2005-07-31 22:18 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Ryan Anderson, git
Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> > Source Code Management with Git
> ....
> The article should include a HOWTO part alos.
I'd vote for a separate file.
> So people can see how to
> edit a file, pull from a remote repository etc.
Exactly.
> Since you have introduced core and porcelains it would be most logical
> to use one of the porcelains in these examples, maybe accompanied by the
> raw git commands being executed.
Better leave the Porcelain-HOWTO to individual Porcelain. Perhaps the
Plumbing-HOWTO should include a section on interfacing to Porcelain (or it
should be yet another file).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v3
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
2005-07-29 10:58 ` Johannes Schindelin
2005-07-29 21:26 ` Sam Ravnborg
@ 2005-07-31 22:15 ` Horst von Brand
2005-08-01 13:21 ` Horst von Brand
2005-08-15 4:55 ` Git 1.0 Synopis (Draft v4) Ryan Anderson
2 siblings, 2 replies; 601+ messages in thread
From: Horst von Brand @ 2005-07-31 22:15 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan Anderson <ryan@michonline.com> wrote:
> Source Code Management with Git
More bugging...
- Either stay with your idea of "Git is the idea, git the implementation"
(iff blessed by the Git Powers That Be) and be consistent about it, or
just use "git" throughout.
- Attribute the meaning appropiately, say by:
In Linus' own words as the inventor of git:
> "git" can mean anything, depending on your mood.
>
> - random three-letter combination that is pronounceable, and not
> actually used by any common UNIX command. The fact that it is a
> mispronunciation of "get" may or may not be relevant.
> - stupid. contemptible and despicable. simple. Take your pick from the
> dictionary of slang.
> - "global information tracker": you're in a good mood, and it actually
> works for you. Angels sing, and a light suddenly fills the room.
> - "goddamn idiotic truckload of sh*t": when it breaks
[...]
> To get a copy of Git:
> Daily snapshots are available at:
> http://www.codemonkey.org.uk/projects/git-snapshots/git/
> (Thanks to Dave Jones)
>
> Source tarballs and RPMs at:
> http://www.kernel.org/pub/software/scm/git/
>
> Deb packages at:
> <insert url here>
>
> Or via Git itself:
> git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
> git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
>
> (rsync is generally faster for an initial clone, you can switch later
> by editing .git/branches/origin and changing the url)
>
> To get the 'Porcelain' tools mentioned above:
> SCM Interface layers:
> cogito - http://www.kernel.org/pub/software/scm/cogito/
> StGIT - http://www.procode.org/stgit/
At least cogito includes a (slightly old) version of git. Dunno about
StGIT. And git and cogito have a gitk inside too. This should be mentioned,
i.e., look at the package(s) you are interested and see what else they
carry or require and keep in mind that (for now?) getting git as part of
one package is /not/ guaranteed to be compatible with another or standard
git.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v3
2005-07-31 22:15 ` Horst von Brand
@ 2005-08-01 13:21 ` Horst von Brand
2005-08-15 4:55 ` Git 1.0 Synopis (Draft v4) Ryan Anderson
1 sibling, 0 replies; 601+ messages in thread
From: Horst von Brand @ 2005-08-01 13:21 UTC (permalink / raw)
To: Horst von Brand; +Cc: Ryan Anderson, git
[Yes, I know it is considered odd when you speak to yourself in public...]
Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git
> More bugging...
And then some.
> > To get the 'Porcelain' tools mentioned above:
> > SCM Interface layers:
> > cogito - http://www.kernel.org/pub/software/scm/cogito/
> > StGIT - http://www.procode.org/stgit/
>
> At least cogito includes a (slightly old) version of git. Dunno about
> StGIT. And git and cogito have a gitk inside too. This should be mentioned,
> i.e., look at the package(s) you are interested and see what else they
> carry or require and keep in mind that (for now?) getting git as part of
> one package is /not/ guaranteed to be compatible with another or standard
> git.
Also note that StGIT is /not/ a SCM (as cogito is), it is a tool to shuffle
patches that uses git as a backend/target.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Git 1.0 Synopis (Draft v4)
2005-07-31 22:15 ` Horst von Brand
2005-08-01 13:21 ` Horst von Brand
@ 2005-08-15 4:55 ` Ryan Anderson
2005-08-15 5:09 ` Ryan Anderson
2005-08-15 5:19 ` Junio C Hamano
1 sibling, 2 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15 4:55 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Junio C Hamano
On Sun, Jul 31, 2005 at 06:15:40PM -0400, Horst von Brand wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git
>
> More bugging...
Ok, I think I've got all this addressed (plus the other email).
It just took me a lot longer to get to it than I planned.
Junio, do you want to pull this into the git tree? (I'll reply with a
patch)
==========
Source Code Management with git
In Linus's own words as the creator of git:
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
git is a "directory content manager". git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o The core git project considers itself to provide "plumbing" for other
projects, as well as to serve to arbitrate for compatibility between them.
The project built on top of the core git are referred to as "porcelain".
Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
tools, and providing an easy to use interface to various pieces of
functionality.
o Some other projects have taken the concepts from the core git project, and
are either porting an existing toolset to use the git tools, or
reimplementing the concepts internally, to benefit from the performance
improvements. This includes both Arch 2.0, and Darcs-git.
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves space and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Debian packages should be availabe in unstable (sid) as "git-core"
Or via git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
(rsync is generally faster for an initial clone, you can switch later
by editing .git/branches/origin and changing the url)
To get the 'Porcelain' tools mentioned above:
SCM Interface layers:
cogito - http://www.kernel.org/pub/software/scm/cogito/
Patch Management (similar to Quilt):
StGIT - http://www.procode.org/stgit/
History Visualization:
gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
distribution)
gitweb - http://www.kernel.org/pub/software/scm/gitweb/
qgit - http://sourceforge.net/projects/qgit
git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
git development takes place on the git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 4:55 ` Git 1.0 Synopis (Draft v4) Ryan Anderson
@ 2005-08-15 5:09 ` Ryan Anderson
2005-08-15 5:19 ` Junio C Hamano
1 sibling, 0 replies; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15 5:09 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Junio C Hamano
Add a SYNOPSIS/release summary to the tree.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
diff --git a/SYNOPSIS b/SYNOPSIS
new file mode 100644
--- /dev/null
+++ b/SYNOPSIS
@@ -0,0 +1,93 @@
+Source Code Management with git
+
+In Linus's own words as the creator of git:
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+ actually used by any common UNIX command. The fact that it is a
+ mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+ dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+ works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+git is a "directory content manager". git has been designed to handle
+absolutely massive projects with speed and efficiency, and the release of the
+2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
+does this task well.
+
+git falls into the category of distributed source code management tools,
+similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every git
+working directory is a full-fledged repository with full revision tracking
+capabilities, not dependent on network access to a central server.
+
+git provides a content-addressable pseudo filesystem, complete with its own
+version of fsck.
+
+ o Speed of use, both for the project maintainer, and the end-users, is
+ a key development principle.
+
+ o The history is stored as a directed acyclic graph, making long-lived
+ branches and repeated merging simple.
+
+ o The core git project considers itself to provide "plumbing" for other
+ projects, as well as to serve to arbitrate for compatibility between them.
+ The project built on top of the core git are referred to as "porcelain".
+ Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
+ tools, and providing an easy to use interface to various pieces of
+ functionality.
+
+ o Some other projects have taken the concepts from the core git project, and
+ are either porting an existing toolset to use the git tools, or
+ reimplementing the concepts internally, to benefit from the performance
+ improvements. This includes both Arch 2.0, and Darcs-git.
+
+ o Two, interchangeable, on-disk formats are used:
+ o An efficient, packed format that saves space and network
+ bandwidth.
+ o An unpacked format, optimized for fast writes and incremental
+ work.
+
+To get a copy of git:
+ Daily snapshots are available at:
+ http://www.codemonkey.org.uk/projects/git-snapshots/git/
+ (Thanks to Dave Jones)
+
+ Source tarballs and RPMs at:
+ http://www.kernel.org/pub/software/scm/git/
+
+ Debian packages should be availabe in unstable (sid) as "git-core"
+
+ Or via git itself:
+ git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
+ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
+
+ (rsync is generally faster for an initial clone, you can switch later
+ by editing .git/branches/origin and changing the url)
+
+To get the 'Porcelain' tools mentioned above:
+ SCM Interface layers:
+ cogito - http://www.kernel.org/pub/software/scm/cogito/
+
+ Patch Management (similar to Quilt):
+ StGIT - http://www.procode.org/stgit/
+
+ History Visualization:
+ gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
+ distribution)
+ gitweb - http://www.kernel.org/pub/software/scm/gitweb/
+ qgit - http://sourceforge.net/projects/qgit
+
+
+git distributions contain a tutorial in the Documentation subdirectory.
+Additionally, the Kernel-Hacker's git Tutorial at
+http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
+that document)
+
+git development takes place on the git mailing list. To subscribe, send an
+email with just "subscribe git" in the body to majordomo@vger.kernel.org.
+Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
+
+(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
+with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 4:55 ` Git 1.0 Synopis (Draft v4) Ryan Anderson
2005-08-15 5:09 ` Ryan Anderson
@ 2005-08-15 5:19 ` Junio C Hamano
2005-08-15 6:58 ` Ryan Anderson
1 sibling, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15 5:19 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan Anderson <ryan@michonline.com> writes:
> Junio, do you want to pull this into the git tree?
Yes, but I have been wondering where it should go. Should it go
under Documentation/ and made into html via asciidoc along with
other tools?
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 5:19 ` Junio C Hamano
@ 2005-08-15 6:58 ` Ryan Anderson
2005-08-15 7:17 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Aug 14, 2005 at 10:19:18PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > Junio, do you want to pull this into the git tree?
>
> Yes, but I have been wondering where it should go. Should it go
> under Documentation/ and made into html via asciidoc along with
> other tools?
I was somewhat thinking it should go in the main directory, and be a
useful introduction to the project for people.... but it's not really
aimed at that very well, now that I think about it.
To be fair, it's not really aimed well at being documentation for people
that already have git, either. I've been writing it with the idea of
"something to send to LWN when 1.0 happens so they can post it mostly
verbatim."
I guess this means, "I dunno, either place works for me."
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 6:58 ` Ryan Anderson
@ 2005-08-15 7:17 ` Junio C Hamano
2005-08-15 8:02 ` Ryan Anderson
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15 7:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan Anderson <ryan@michonline.com> writes:
> I guess this means, "I dunno, either place works for me."
I was hoping it means to "Oh, come to think of it, maybe I
should send this to corbet@lwn.net" ;-).
I agree with you that this may be a lot more suitable for people
_before_ they get the git sources, which is to say it may make
more sense not to include in core-git tarball but is made into a
patch to Pasky's introduction website.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 7:17 ` Junio C Hamano
@ 2005-08-15 8:02 ` Ryan Anderson
2005-08-15 8:17 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Ryan Anderson @ 2005-08-15 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, Aug 15, 2005 at 12:17:46AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > I guess this means, "I dunno, either place works for me."
>
> I was hoping it means to "Oh, come to think of it, maybe I
> should send this to corbet@lwn.net" ;-).
I was waiting until you said, "Ok, 1.00 tomorrow morning"
> I agree with you that this may be a lot more suitable for people
> _before_ they get the git sources, which is to say it may make
> more sense not to include in core-git tarball but is made into a
> patch to Pasky's introduction website.
Good point.
It's already there (now that I found the site.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 8:02 ` Ryan Anderson
@ 2005-08-15 8:17 ` Junio C Hamano
2005-08-15 18:59 ` Daniel Barkalow
0 siblings, 1 reply; 601+ messages in thread
From: Junio C Hamano @ 2005-08-15 8:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan Anderson <ryan@michonline.com> writes:
> I was waiting until you said, "Ok, 1.00 tomorrow morning"
Makes sense. There would be some weeks until that happens I am
afraid.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 8:17 ` Junio C Hamano
@ 2005-08-15 18:59 ` Daniel Barkalow
2005-08-16 7:28 ` Junio C Hamano
0 siblings, 1 reply; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-15 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > I was waiting until you said, "Ok, 1.00 tomorrow morning"
>
> Makes sense. There would be some weeks until that happens I am
> afraid.
It might be worth putting the list of things left to do before 1.0 in the
tree (since they clearly covary), and it would be useful to know what
you're thinking of as preventing the release at any particular stage.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-15 18:59 ` Daniel Barkalow
@ 2005-08-16 7:28 ` Junio C Hamano
2005-08-16 10:03 ` Johannes Schindelin
` (3 more replies)
0 siblings, 4 replies; 601+ messages in thread
From: Junio C Hamano @ 2005-08-16 7:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ryan Anderson, git
Daniel Barkalow <barkalow@iabervon.org> writes:
> It might be worth putting the list of things left to do before 1.0 in the
> tree (since they clearly covary), and it would be useful to know what
> you're thinking of as preventing the release at any particular stage.
Yeah, yeah. Call me lazy.
Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
random other messages since then.
- Documentation. [I really need help here --- among ~7000 lines
there, I've written around 2500 lines, David Greaves another
2500, and Linus 1400. And it is not very easy to proofread
what you wrote yourself.]
- Are all the core commands described in Documentation/
directory?
- Many files under Documentation/ directory have become stale.
I've tried to do one pass of full sweep recently [and
another since I wrote the original "last mile" message], but
I'd like somebody else to make another pass to make sure
that the usage strings in programs, what the programs do,
and what Documentation says they do match. Also, the
spelling and grammar fixes, which I am very bad at and have
not done any attempt, needs to be done.
Volunteers?
- Are all the files in Documentation/ reachable from git(7)
or otherwise made into a standalone document using asciidoc
by the Makefile? I haven't looked into documentation
generation myself (I use only the text files as they are);
help to update the Makefile by somebody handy with asciidoc
suite is greatly appreciated here.
Volunteers?
- We may want to describe more Best Current Practices, along
the lines of "Working with Others" section in the tutorial.
Please write on your faviorite topic and send patches in
;-)) [ryan started collecting Documentation/howto which
would greatly help in this area].
- Glossary documentation Johannes Schindelin is working on.
I think coming up with the concensus of terms would come
fairly quickly on the list. Updating docs to match the
concensus may take some time. Help is greatly appreciated.
- Maybe doing another pass at tutorial. Could somebody run
(or preferably, find a friend who has never touched git and
have her run) the tutorial examples from the beginning to
the end, and find rooms of improvements? Does the order of
materials presented make sense? Do we talk about things
assuming that the user knows something else that we have not
talked about? Have we introduced better way of doing the
same thing since the tutorial was written?
I've done that once with the text that is currently in the
head of the master branch, but that is getting rather stale,
and also I did that myself so I am sure I've sidestepped
pitfalls without even realizing.
The above does not have to be all there in 0.99.5, but I
consider that lack of any of the above to block 1.0.
- Commit walker downloading from packed repository is finally
complete. Thanks, Daniel!
- Teach fetch-pack reference renaming.
On the push side, send-pack now knows updating arbitrary
remote references from local references. We need something
similar for fetching [since then I outlined the design of the
new shorthand file format and semantics but have not got
around to actually do it. Maybe on my next GIT day...]. This
is scheduled for 0.99.5.
- commit template filler discussed with Pasky some time ago,
with perhaps pre-commit and post-commit hooks. Somehow the
discussion died out but that does not mean _I_ forgot about
it.
- Binary packaging. Should _I_ worry about "/usr/bin/git" stay
there myself --- I think not. But I _do_ want to help Debian
packaging folks if that path is causing problems in their
effort to push git-core into the official Debian archive.
As Linus mentioned earlier, this seems to be a Debian specific
problem, and will not block 1.0 --- if Debian heavyweights do
not want to stay compatible with the rest of the world, so be
it.
- I have not heard from Darwin or BSD people for some time. Is
your portfile up to date? Do you have updates you want me to
include? Have we introduced non-Linux non-GNU
incompatibilities lately that you want to see fixed and/or
worked around?
Again, I consider binary packaging issue independent from our
release schedule; it is a distribution local issue, so this
would not block 1.0 in any way. But I _am_ willing to help
them.
- Oh, another itch I did not list in the previous message. Is
anybody interested in doing an Emacs VC back-end for GIT?
- git prune and git fsck-cache; think about their interactions
with an object database that borrows from another. This
includes the case where .git/objects itself is symlinked to
somewhere else (i.e. running "git prune" that somewhere else
without consulting this repository would lose objects), and
alternates pointing at somewhere else (i.e. ditto).
My personal feeling is that we should just warn users about
doing .git/objects symlinking and/or alternates pointing ---
do not do it unless you have an off-line arrangement with the
owner of the repository you are borrowing from. Even if that
would become our official position to take, it needs to be
documented clearly before we declare this issue to have been
"dealt with".
I am sure I am forgetting something, but the above would be a
good start.
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 7:28 ` Junio C Hamano
@ 2005-08-16 10:03 ` Johannes Schindelin
2005-08-16 10:14 ` Dongsheng Song
2005-08-16 10:17 ` about git server & permissions Dongsheng Song
2005-08-16 15:31 ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
` (2 subsequent siblings)
3 siblings, 2 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 978 bytes --]
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Glossary documentation Johannes Schindelin is working on.
Yeah, yeah. Call _me_ lazy :-) I'll try to come up with a discussable item
today.
> - git prune and git fsck-cache; think about their interactions
> with an object database that borrows from another. This
> includes the case where .git/objects itself is symlinked to
> somewhere else (i.e. running "git prune" that somewhere else
> without consulting this repository would lose objects), and
> alternates pointing at somewhere else (i.e. ditto).
I don´t see how git could help in the case you are pruning a repository
which another repository points to. After all, the first repository
doesn´t know about being used by the second.
> I am sure I am forgetting something, but the above would be a
> good start.
Maybe your $GIT_DIR/remotes idea? Along with a "--store <remotename>" flag
to git-pull-script?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 7:28 ` Junio C Hamano
2005-08-16 10:03 ` Johannes Schindelin
@ 2005-08-16 15:31 ` Johannes Schindelin
2005-08-16 15:47 ` Daniel Barkalow
2005-08-16 15:39 ` Daniel Barkalow
2005-08-16 19:41 ` Horst von Brand
3 siblings, 1 reply; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 15:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1072 bytes --]
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Are all the files in Documentation/ reachable from git(7)
> or otherwise made into a standalone document using asciidoc
> by the Makefile? I haven't looked into documentation
> generation myself (I use only the text files as they are);
> help to update the Makefile by somebody handy with asciidoc
> suite is greatly appreciated here.
>
> Volunteers?
The attached script reveals:
git-unpack-objects.txt is not reachable from git.txt
git-cvsimport-script.txt is not reachable from git.txt
git-send-email-script.txt is not reachable from git.txt
git-rename-script.txt is not reachable from git.txt
tutorial.txt is not reachable from git.txt
git-show-index.txt is not reachable from git.txt
cvs-migration.txt is not reachable from git.txt
diffcore.txt is not reachable from git.txt
git-ls-remote-script.txt is not reachable from git.txt
git-apply.txt is not reachable from git.txt
git-diff-stages.txt is not reachable from git.txt
pack-protocol.txt is not reachable from git.txt
Ciao,
Dscho
[-- Attachment #2: Type: APPLICATION/x-perl, Size: 1215 bytes --]
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 15:31 ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
@ 2005-08-16 15:47 ` Daniel Barkalow
0 siblings, 0 replies; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-16 15:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Ryan Anderson, git
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> > - Are all the files in Documentation/ reachable from git(7)
> > or otherwise made into a standalone document using asciidoc
> > by the Makefile? I haven't looked into documentation
> > generation myself (I use only the text files as they are);
> > help to update the Makefile by somebody handy with asciidoc
> > suite is greatly appreciated here.
> >
> > Volunteers?
>
> The attached script reveals:
>
> git-unpack-objects.txt is not reachable from git.txt
> git-cvsimport-script.txt is not reachable from git.txt
> git-send-email-script.txt is not reachable from git.txt
> git-rename-script.txt is not reachable from git.txt
> tutorial.txt is not reachable from git.txt
> git-show-index.txt is not reachable from git.txt
> cvs-migration.txt is not reachable from git.txt
> diffcore.txt is not reachable from git.txt
> git-ls-remote-script.txt is not reachable from git.txt
> git-apply.txt is not reachable from git.txt
> git-diff-stages.txt is not reachable from git.txt
> pack-protocol.txt is not reachable from git.txt
The ones that don't start with git probably don't belong in the same set;
perhaps there should be a "technical" (or something similar but shorter)
subdirectory for developer documentation instead of user documentation?
(And tutorial and cvs-migration can move to howto)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 7:28 ` Junio C Hamano
2005-08-16 10:03 ` Johannes Schindelin
2005-08-16 15:31 ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
@ 2005-08-16 15:39 ` Daniel Barkalow
2005-08-16 19:41 ` Horst von Brand
3 siblings, 0 replies; 601+ messages in thread
From: Daniel Barkalow @ 2005-08-16 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It might be worth putting the list of things left to do before 1.0 in the
> > tree (since they clearly covary), and it would be useful to know what
> > you're thinking of as preventing the release at any particular stage.
>
> Yeah, yeah. Call me lazy.
>
> Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
> random other messages since then.
>
> - Documentation. [I really need help here --- among ~7000 lines
> there, I've written around 2500 lines, David Greaves another
> 2500, and Linus 1400. And it is not very easy to proofread
> what you wrote yourself.]
I'm not sure how done this can actually get before some sort of feature
freeze; the best ways to do things keeps changing as more convenient ways
are added. Once the new stuff is diverted to post-1.0, I'd be interested
in going through it.
> - git prune and git fsck-cache; think about their interactions
> with an object database that borrows from another. This
> includes the case where .git/objects itself is symlinked to
> somewhere else (i.e. running "git prune" that somewhere else
> without consulting this repository would lose objects), and
> alternates pointing at somewhere else (i.e. ditto).
It should be fine, but only if .git/refs is symlinked to the matching
place; this gives you the same repository with multiple working trees.
Having refs/ and objects/ directories that aren't always together would be
much less safe.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 7:28 ` Junio C Hamano
` (2 preceding siblings ...)
2005-08-16 15:39 ` Daniel Barkalow
@ 2005-08-16 19:41 ` Horst von Brand
2005-08-16 20:41 ` Johannes Schindelin
2005-08-18 9:27 ` Matthias Urlichs
3 siblings, 2 replies; 601+ messages in thread
From: Horst von Brand @ 2005-08-16 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
Junio C Hamano <junkio@cox.net> wrote:
[...]
> - Oh, another itch I did not list in the previous message. Is
> anybody interested in doing an Emacs VC back-end for GIT?
And teach make(1) about checking out files from git... or just create a
co(1) command for git.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 19:41 ` Horst von Brand
@ 2005-08-16 20:41 ` Johannes Schindelin
2005-08-18 9:27 ` Matthias Urlichs
1 sibling, 0 replies; 601+ messages in thread
From: Johannes Schindelin @ 2005-08-16 20:41 UTC (permalink / raw)
To: Horst von Brand; +Cc: Junio C Hamano, Daniel Barkalow, Ryan Anderson, git
Hi,
On Tue, 16 Aug 2005, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
How about "git-checkout-script", optionally with the "-f" flag to ignore
changes since the last checkout/checkin?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 601+ messages in thread
* Re: Git 1.0 Synopis (Draft v4)
2005-08-16 19:41 ` Horst von Brand
2005-08-16 20:41 ` Johannes Schindelin
@ 2005-08-18 9:27 ` Matthias Urlichs
1 sibling, 0 replies; 601+ messages in thread
From: Matthias Urlichs @ 2005-08-18 9:27 UTC (permalink / raw)
To: git
Hi, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
Ummm... why?
make's SCCS support depends on the presence of a SCCS/s.<name> file
for each <name>. We don't have that. Teaching make about git would be
equivalent to teaching it about parsing the index file.
Technically, that would require a stable libgit.so or so.
In reality, however, I don't know when I last had a tree which wasn't
fully populated, but it's been a while, and it's something that can be
readily fixed by "git-checkout-cache -a".
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.
^ permalink raw reply [flat|nested] 601+ messages in thread
end of thread, other threads:[~2008-07-21 7:10 UTC | newest]
Thread overview: 601+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-13 21:35 What's in git.git (stable) Junio C Hamano
2006-12-13 22:37 ` Andy Parkins
2006-12-13 22:48 ` Jakub Narebski
2006-12-14 9:27 ` Andy Parkins
2006-12-14 9:36 ` Shawn Pearce
2006-12-14 10:03 ` Andy Parkins
2006-12-14 17:06 ` Nicolas Pitre
2006-12-15 14:28 ` Jakub Narebski
2006-12-13 23:31 ` Junio C Hamano
2006-12-13 23:52 ` Peter Baumann
2006-12-14 0:16 ` Johannes Schindelin
2006-12-14 3:32 ` Nicolas Pitre
2006-12-14 6:29 ` Junio C Hamano
2006-12-14 7:59 ` git-show, was " Johannes Schindelin
2006-12-14 8:28 ` Junio C Hamano
2006-12-14 10:25 ` Johannes Schindelin
2006-12-14 8:28 ` Andreas Ericsson
2006-12-15 14:39 ` Jakub Narebski
2006-12-14 9:59 ` Andy Parkins
2006-12-14 10:21 ` Junio C Hamano
2006-12-14 11:36 ` Andy Parkins
2006-12-14 11:45 ` Shawn Pearce
2006-12-14 11:58 ` Carl Worth
2006-12-14 12:05 ` Shawn Pearce
2006-12-14 14:03 ` reflog by default?, was " Johannes Schindelin
2006-12-14 18:06 ` Nicolas Pitre
2006-12-14 19:52 ` Junio C Hamano
2006-12-14 20:02 ` Shawn Pearce
2006-12-14 20:22 ` Nicolas Pitre
2006-12-14 20:35 ` Junio C Hamano
2006-12-14 22:41 ` [PATCH] Enable reflogs by default in any repository with a working directory Shawn O. Pearce
2006-12-14 23:10 ` J. Bruce Fields
2006-12-14 23:18 ` Shawn Pearce
2006-12-14 23:42 ` J. Bruce Fields
2006-12-15 0:13 ` Johannes Schindelin
2006-12-15 0:20 ` Shawn Pearce
2006-12-15 21:55 ` Junio C Hamano
2006-12-14 22:44 ` What's in git.git (stable) Shawn Pearce
2006-12-14 21:55 ` Andreas Ericsson
2006-12-15 21:55 ` Junio C Hamano
2006-12-16 2:54 ` Shawn Pearce
2006-12-14 20:17 ` Nicolas Pitre
2006-12-14 20:50 ` Junio C Hamano
2006-12-14 19:58 ` [PATCH] Enable reflogs by default in all repositories Shawn O. Pearce
2006-12-14 17:47 ` What's in git.git (stable) Nicolas Pitre
2006-12-14 21:58 ` Junio C Hamano
2006-12-14 22:50 ` Andy Parkins
2006-12-15 15:38 ` Jakub Narebski
2006-12-15 15:26 ` Jakub Narebski
2006-12-15 15:30 ` Nicolas Pitre
2006-12-15 15:48 ` Andreas Ericsson
2006-12-15 16:08 ` Nicolas Pitre
2006-12-15 16:12 ` Shawn Pearce
2006-12-15 16:13 ` Andreas Ericsson
2006-12-15 23:22 ` Johannes Schindelin
2006-12-15 4:07 ` Nicolas Pitre
2006-12-15 4:15 ` [PATCH] make commit message a little more consistent and conforting Nicolas Pitre
2006-12-15 4:24 ` Shawn Pearce
2006-12-15 8:34 ` Andreas Ericsson
2006-12-15 15:09 ` Shawn Pearce
2006-12-15 15:32 ` Andreas Ericsson
2006-12-15 15:40 ` Shawn Pearce
2006-12-15 15:50 ` Andreas Ericsson
2006-12-15 16:06 ` Nicolas Pitre
2006-12-15 18:21 ` Junio C Hamano
2006-12-15 16:01 ` Nicolas Pitre
2006-12-15 16:08 ` Shawn Pearce
2006-12-15 18:14 ` Junio C Hamano
2006-12-15 20:13 ` Nicolas Pitre
2006-12-16 6:18 ` Junio C Hamano
2006-12-14 21:22 ` What's in git.git (stable) Junio C Hamano
2006-12-14 22:55 ` Andy Parkins
2006-12-14 23:46 ` Junio C Hamano
2006-12-15 8:58 ` Andy Parkins
2006-12-15 9:55 ` Raimund Bauer
2006-12-15 21:55 ` Junio C Hamano
2006-12-15 22:54 ` Carl Worth
2006-12-14 23:53 ` Johannes Schindelin
2006-12-14 23:52 ` Horst H. von Brand
2006-12-15 10:53 ` Jakub Narebski
2006-12-14 0:22 ` Johannes Schindelin
2006-12-14 10:21 ` Andy Parkins
2006-12-14 10:51 ` Johannes Schindelin
2006-12-14 11:23 ` Andy Parkins
2006-12-14 11:27 ` Johannes Schindelin
2006-12-14 12:00 ` Andy Parkins
2006-12-14 12:10 ` Shawn Pearce
2006-12-14 13:20 ` Andy Parkins
2006-12-15 0:15 ` Horst H. von Brand
2006-12-15 0:23 ` Johannes Schindelin
2006-12-14 17:23 ` Nicolas Pitre
2006-12-14 21:02 ` Andy Parkins
2006-12-14 23:03 ` Shawn Pearce
2006-12-15 16:16 ` Jakub Narebski
2006-12-15 21:55 ` Junio C Hamano
2006-12-15 22:48 ` Jakub Narebski
2006-12-15 23:25 ` Johannes Schindelin
2006-12-15 23:45 ` Junio C Hamano
2006-12-16 0:14 ` Johannes Schindelin
2006-12-16 0:30 ` Junio C Hamano
2006-12-16 17:12 ` Steven Grimm
2006-12-16 19:57 ` Junio C Hamano
2006-12-15 23:42 ` Junio C Hamano
2006-12-16 9:14 ` [PATCH] git-clone: use wildcard specification for tracking branches Junio C Hamano
2006-12-16 9:36 ` [PATCH] git-pull: refuse default merge without branch.*.merge Junio C Hamano
2006-12-16 9:41 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Junio C Hamano
2006-12-16 9:53 ` [PATCH] git-clone: lose the traditional 'no-separate-remote' layout Junio C Hamano
2006-12-16 16:53 ` Linus Torvalds
2006-12-16 11:51 ` [PATCH] git-clone: lose the artificial "first" fetch refspec Johannes Schindelin
2006-12-16 16:44 ` [PATCH] git-pull: refuse default merge without branch.*.merge Linus Torvalds
2006-12-16 9:39 ` [PATCH] git-clone: use wildcard specification for tracking branches Jakub Narebski
2006-12-16 9:58 ` What's in git.git (stable) Junio C Hamano
2006-12-16 11:22 ` [PATCH] Document git-merge-file Johannes Schindelin
2006-12-16 13:59 ` What's in git.git (stable) Jakub Narebski
2006-12-16 22:04 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2008-07-21 7:09 Junio C Hamano
2008-04-09 6:51 [ANNOUNCE] GIT 1.5.5 Junio C Hamano
2008-04-09 9:44 ` What's in git.git (stable) Junio C Hamano
2008-04-14 7:00 ` Junio C Hamano
2008-04-19 8:18 ` Junio C Hamano
2008-04-27 6:04 ` Junio C Hamano
2008-05-06 6:38 ` Junio C Hamano
2008-05-14 22:35 ` Junio C Hamano
2008-05-24 1:32 ` Junio C Hamano
2008-05-30 20:43 ` Junio C Hamano
2008-06-02 8:01 ` Junio C Hamano
2008-06-13 10:10 ` Junio C Hamano
2008-06-18 7:32 ` Junio C Hamano
2008-06-18 10:59 ` Jeff King
2008-06-21 10:06 ` Junio C Hamano
2008-06-23 7:25 ` Junio C Hamano
2008-06-25 9:34 ` Junio C Hamano
2008-07-02 6:28 ` Junio C Hamano
2008-07-06 10:04 ` Junio C Hamano
2008-07-08 2:46 ` Junio C Hamano
2008-07-14 5:33 ` Junio C Hamano
2008-07-16 3:33 ` Junio C Hamano
2008-07-20 1:59 ` Junio C Hamano
2008-07-20 11:20 ` Lars Noschinski
2008-07-20 18:27 ` Junio C Hamano
2008-01-30 8:32 What's in git.git (stable frozen) Junio C Hamano
2008-02-12 7:25 ` What's in git.git Junio C Hamano
2008-02-17 3:56 ` What's in git.git (stable) Junio C Hamano
2008-02-17 13:39 ` Jakub Narebski
2008-02-17 20:45 ` Junio C Hamano
2008-02-17 20:51 ` Johannes Schindelin
2008-02-18 1:31 ` Junio C Hamano
2008-02-18 1:34 ` Johannes Schindelin
2008-02-18 1:43 ` Jeff King
2008-02-18 2:05 ` Johannes Schindelin
2008-02-18 3:12 ` Junio C Hamano
2008-02-18 11:15 ` Jeff King
2008-02-21 4:16 ` Junio C Hamano
2008-02-25 8:42 ` Junio C Hamano
2008-02-28 0:43 ` Junio C Hamano
2008-03-03 2:06 ` Junio C Hamano
2008-03-06 6:02 ` Junio C Hamano
2008-03-08 10:08 ` Junio C Hamano
2008-03-09 10:46 ` Junio C Hamano
2008-03-14 9:11 ` Junio C Hamano
2008-03-23 10:08 ` Junio C Hamano
2008-03-28 1:45 ` Junio C Hamano
2008-03-31 8:39 ` Junio C Hamano
2008-04-04 18:24 ` Junio C Hamano
2008-04-05 3:13 ` Shawn O. Pearce
2008-01-14 1:53 Junio C Hamano
2007-10-22 6:11 What's in git/spearce.git (stable) Shawn O. Pearce
2007-11-01 5:39 ` What's in git.git (stable) Junio C Hamano
2007-11-04 3:52 ` Junio C Hamano
2007-11-08 8:06 ` Junio C Hamano
2007-11-08 11:38 ` Pierre Habouzit
2007-11-12 7:06 ` Junio C Hamano
2007-11-15 0:20 ` Junio C Hamano
2007-11-17 21:00 ` Junio C Hamano
2007-11-25 20:45 ` Junio C Hamano
2007-12-01 2:05 ` Junio C Hamano
2007-12-04 8:43 ` Junio C Hamano
2007-12-05 10:57 ` Junio C Hamano
2007-12-07 9:50 ` Junio C Hamano
2007-12-09 10:32 ` Junio C Hamano
2007-09-06 8:52 Junio C Hamano
[not found] ` <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
2007-09-26 20:05 ` Junio C Hamano
2007-10-02 5:52 ` Junio C Hamano
2007-08-23 0:37 Junio C Hamano
2007-08-24 0:28 ` Jakub Narebski
2007-08-11 8:41 Junio C Hamano
2007-08-11 9:32 ` David Kastrup
2007-08-16 5:02 ` Junio C Hamano
2007-05-13 22:30 Junio C Hamano
2007-05-17 0:21 ` Junio C Hamano
2007-05-19 5:24 ` Junio C Hamano
2007-05-23 21:46 ` Junio C Hamano
2007-05-29 10:12 ` Junio C Hamano
2007-06-02 21:09 ` Junio C Hamano
2007-06-07 2:08 ` Junio C Hamano
2007-06-13 20:11 ` Junio C Hamano
2007-06-13 22:31 ` Johannes Schindelin
2007-06-14 7:12 ` Johannes Sixt
2007-06-21 7:21 ` Junio C Hamano
2007-06-25 9:43 ` Junio C Hamano
2007-07-02 0:16 ` Junio C Hamano
2007-07-13 6:06 ` What's in git.git Junio C Hamano
2007-07-28 8:47 ` What's in git.git (stable) Junio C Hamano
2007-07-28 8:56 ` David Kastrup
2007-07-28 9:02 ` Junio C Hamano
2007-07-28 9:35 ` David Kastrup
2007-07-29 3:16 ` Theodore Tso
2007-07-29 9:05 ` David Kastrup
2007-07-29 16:40 ` Theodore Tso
2007-07-29 11:27 ` Johannes Schindelin
2007-07-28 12:28 ` Thomas Glanzmann
2007-08-07 6:22 ` Junio C Hamano
2007-05-09 8:46 Junio C Hamano
2007-04-16 1:27 Junio C Hamano
2007-04-18 23:58 ` Junio C Hamano
2007-04-22 6:22 ` Junio C Hamano
2007-04-23 7:04 ` Junio C Hamano
2007-04-27 8:34 ` Junio C Hamano
2007-04-27 9:19 ` Andy Parkins
2007-04-27 14:01 ` Nicolas Pitre
2007-04-27 15:21 ` Andy Parkins
2007-04-27 17:11 ` Linus Torvalds
2007-04-27 18:03 ` Andy Parkins
2007-04-27 18:12 ` Linus Torvalds
2007-04-29 18:33 ` Junio C Hamano
2007-04-30 4:15 ` J. Bruce Fields
2007-04-30 5:12 ` Junio C Hamano
2007-05-01 3:36 ` J. Bruce Fields
2007-05-06 8:53 ` Junio C Hamano
2007-05-07 0:59 ` Jakub Narebski
2007-05-07 13:33 ` Frank Lichtenheld
2007-04-09 8:17 Junio C Hamano
2007-03-31 9:34 Junio C Hamano
2007-03-31 11:54 ` Alex Riesen
2007-04-05 6:44 ` Junio C Hamano
2007-02-20 7:32 Junio C Hamano
2007-02-23 8:33 ` Junio C Hamano
2007-03-04 10:32 ` Junio C Hamano
2007-03-13 8:49 ` Junio C Hamano
2007-03-13 9:26 ` Junio C Hamano
2007-03-22 17:08 ` Steven Grimm
2007-03-22 21:30 ` Junio C Hamano
2007-03-25 8:32 ` Junio C Hamano
2007-02-14 23:54 Junio C Hamano
2007-02-07 23:21 [ANNOUNCE] GIT 1.5.0-rc4 Junio C Hamano
2007-02-13 5:15 ` What's in git.git (stable) Junio C Hamano
2007-02-13 10:15 ` Johannes Schindelin
2007-02-13 17:33 ` Junio C Hamano
2007-02-13 18:21 ` Randal L. Schwartz
2007-02-13 18:37 ` Johannes Schindelin
2007-02-13 22:02 ` Jimmy Tang
2007-02-13 23:31 ` Linus Torvalds
2007-02-13 13:56 ` Matthias Lederhofer
2007-02-13 16:58 ` Junio C Hamano
2007-02-13 14:33 ` Bill Lear
2007-02-13 14:37 ` Bill Lear
2007-02-13 17:18 ` Randal L. Schwartz
2007-02-01 0:26 [ANNOUNCE] GIT 1.5.0-rc3 Junio C Hamano
2007-02-04 9:36 ` What's in git.git (stable) Junio C Hamano
2007-02-04 18:51 ` Jeff King
2007-02-04 19:12 ` Linus Torvalds
2007-02-04 20:58 ` Theodore Tso
2007-02-04 21:34 ` Jakub Narebski
2007-02-04 22:25 ` David Kågedal
2007-01-27 8:05 Junio C Hamano
2007-01-27 8:59 ` Aneesh Kumar K.V
2007-01-27 18:06 ` J. Bruce Fields
2007-01-27 22:00 ` Junio C Hamano
2007-01-27 17:56 ` J. Bruce Fields
2007-01-28 19:34 ` Bill Lear
2007-01-28 20:06 ` Junio C Hamano
2007-01-10 8:24 Junio C Hamano
2007-01-10 8:23 Junio C Hamano
2007-01-02 0:07 Junio C Hamano
2007-01-07 7:43 ` Junio C Hamano
2006-12-31 8:07 Junio C Hamano
2006-12-27 7:39 [RFH] An early draft of v1.5.0 release notes Junio C Hamano
2006-12-27 8:18 ` Shawn Pearce
2006-12-27 10:12 ` Jakub Narebski
2006-12-27 10:24 ` Junio C Hamano
2006-12-27 11:54 ` Johannes Schindelin
2006-12-27 12:15 ` Jakub Narebski
2006-12-27 12:12 ` Jakub Narebski
2006-12-27 13:00 ` Horst H. von Brand
2006-12-27 19:42 ` Junio C Hamano
2006-12-28 0:49 ` Junio C Hamano
2006-12-28 1:44 ` Nicolas Pitre
2006-12-29 11:56 ` David Kågedal
2006-12-27 19:45 ` Junio C Hamano
2006-12-28 0:32 ` Jakub Narebski
2006-12-27 10:50 ` Junio C Hamano
2006-12-27 12:06 ` Horst H. von Brand
2006-12-28 2:58 ` Junio C Hamano
2006-12-28 11:50 ` Jakub Narebski
2006-12-28 1:45 ` An early draft of v1.5.0 release notes (2nd ed) Junio C Hamano
2006-12-28 2:03 ` Shawn Pearce
2006-12-28 2:20 ` Junio C Hamano
2006-12-28 2:28 ` Shawn Pearce
2006-12-28 2:41 ` Junio C Hamano
2006-12-28 2:47 ` Shawn Pearce
2006-12-28 5:54 ` Junio C Hamano
2007-01-10 7:58 ` An early draft of v1.5.0 release notes (3rd ed) Junio C Hamano
2006-12-28 3:03 ` [RFH] An early draft of v1.5.0 release notes Eric Wong
2006-12-28 5:34 ` Junio C Hamano
2006-12-26 3:22 What's in git.git (stable) and announcing GIT 1.5.0 preview Junio C Hamano
2006-12-29 5:44 ` What's in git.git (stable) Junio C Hamano
2006-12-22 9:25 Junio C Hamano
2006-12-22 17:15 ` Randal L. Schwartz
2006-12-22 17:19 ` Randal L. Schwartz
2006-12-22 18:09 ` Johannes Schindelin
2006-12-22 18:12 ` Randal L. Schwartz
2006-12-22 18:21 ` Randal L. Schwartz
2006-12-22 19:21 ` Johannes Schindelin
2006-12-22 20:13 ` Junio C Hamano
2006-12-22 20:44 ` Johannes Schindelin
2006-12-22 21:44 ` Junio C Hamano
2006-12-26 20:25 ` Luben Tuikov
2006-12-26 23:54 ` Junio C Hamano
2006-12-27 1:19 ` Luben Tuikov
2006-12-27 2:14 ` Junio C Hamano
2006-12-22 18:58 ` Junio C Hamano
2006-12-22 20:04 ` Jakub Narebski
2006-12-22 20:16 ` Junio C Hamano
2006-12-22 20:56 ` Jakub Narebski
2006-12-22 21:49 ` Junio C Hamano
2006-12-22 20:21 ` Quy Tonthat
2006-12-18 7:26 Junio C Hamano
[not found] ` <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
2006-12-18 22:04 ` Junio C Hamano
2006-12-16 23:10 Junio C Hamano
2006-12-06 21:18 Junio C Hamano
2006-12-08 15:36 ` Jakub Narebski
2006-12-09 20:44 ` Tilman Sauerbeck
2006-12-09 21:10 ` Junio C Hamano
2006-11-14 16:42 [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Carl Worth
2006-11-14 18:55 ` Andy Whitcroft
2006-11-14 19:22 ` Cleaning up git user-interface warts Carl Worth
2006-11-14 19:29 ` Shawn Pearce
2006-11-14 19:59 ` Carl Worth
2006-11-14 19:47 ` Petr Baudis
2006-11-14 20:56 ` Carl Worth
2006-11-15 0:31 ` Junio C Hamano
2006-11-15 4:08 ` Petr Baudis
2006-11-15 4:33 ` Junio C Hamano
2006-11-15 4:46 ` Nicolas Pitre
2006-11-15 10:09 ` Jakub Narebski
2006-11-15 10:15 ` Santi Béjar
2006-11-15 10:28 ` Jakub Narebski
2006-11-16 2:43 ` Petr Baudis
2006-11-15 14:56 ` Nicolas Pitre
2006-11-15 20:39 ` Petr Baudis
2006-11-15 10:05 ` Jakub Narebski
2006-11-15 10:25 ` Karl Hasselström
2006-11-15 20:51 ` Carl Worth
2006-11-15 20:57 ` Jakub Narebski
2006-11-15 22:00 ` Shawn Pearce
2006-11-15 22:17 ` Carl Worth
2006-11-17 20:30 ` Steven Grimm
2006-11-17 21:35 ` Junio C Hamano
2006-11-17 22:07 ` Petr Baudis
2006-11-14 20:46 ` Karl Hasselström
2006-11-14 20:52 ` Nicolas Pitre
2006-11-14 21:01 ` Jakub Narebski
2006-11-14 21:32 ` Nicolas Pitre
2006-11-14 22:04 ` Jakub Narebski
2006-11-14 22:29 ` Nicolas Pitre
2006-11-14 21:10 ` Carl Worth
2006-11-14 21:30 ` Jakub Narebski
2006-11-14 21:34 ` Nicolas Pitre
2006-11-14 22:56 ` Junio C Hamano
2006-11-15 1:48 ` Nicolas Pitre
2006-11-15 2:10 ` Junio C Hamano
2006-11-15 2:27 ` Michael K. Edwards
2006-11-15 4:20 ` Nicolas Pitre
2006-11-15 4:58 ` Junio C Hamano
2006-11-15 18:03 ` Linus Torvalds
2006-11-15 18:28 ` Jakub Narebski
2006-11-15 20:31 ` Josef Weidendorfer
2006-11-15 20:35 ` Petr Baudis
2006-11-15 21:12 ` Josef Weidendorfer
2006-11-15 21:31 ` Linus Torvalds
2006-11-15 18:43 ` Nicolas Pitre
2006-11-15 18:49 ` Shawn Pearce
2006-11-15 19:05 ` Marko Macek
2006-11-15 20:41 ` Junio C Hamano
2006-11-15 22:07 ` Shawn Pearce
2006-11-16 6:07 ` Marko Macek
2006-11-16 10:36 ` Junio C Hamano
2006-11-17 13:45 ` Jakub Narebski
2006-11-15 22:28 ` Sean
[not found] ` <20061115172834.0a328154.seanlkml@sympatico.ca>
2006-11-16 3:07 ` Petr Baudis
2006-11-15 18:58 ` Andy Parkins
2006-11-15 19:18 ` Linus Torvalds
2006-11-15 19:39 ` Michael K. Edwards
2006-11-15 20:09 ` Linus Torvalds
2006-11-15 20:21 ` Nicolas Pitre
2006-11-15 20:40 ` Linus Torvalds
2006-11-15 21:08 ` Carl Worth
2006-11-15 21:31 ` Junio C Hamano
2006-11-15 21:40 ` Nicolas Pitre
2006-11-15 21:52 ` Junio C Hamano
2006-11-15 21:59 ` Nicolas Pitre
2006-11-17 12:20 ` Karl Hasselström
2006-11-15 21:45 ` Linus Torvalds
2006-11-15 22:52 ` Carl Worth
2006-11-15 23:02 ` Shawn Pearce
2006-11-15 23:33 ` Linus Torvalds
2006-11-16 0:08 ` Nicolas Pitre
2006-11-16 3:07 ` Linus Torvalds
2006-11-16 3:43 ` Nicolas Pitre
2006-11-16 3:02 ` Michael K. Edwards
2006-11-16 11:35 ` Andreas Ericsson
2006-11-16 16:37 ` Carl Worth
2006-11-16 17:57 ` Michael K. Edwards
2006-11-16 18:23 ` Carl Worth
2006-11-17 8:41 ` Junio C Hamano
2006-11-17 9:18 ` Carl Worth
2006-11-17 10:11 ` Johannes Schindelin
2006-11-17 11:41 ` Junio C Hamano
2006-11-17 16:58 ` Shawn Pearce
2006-11-17 11:29 ` Junio C Hamano
2006-11-15 23:07 ` Sean
[not found] ` <20061115180722.83ff8990.seanlkml@sympatico.ca>
2006-11-15 23:15 ` Shawn Pearce
2006-11-16 7:51 ` Richard CURNOW
2006-11-16 23:01 ` Johannes Schindelin
2006-11-21 13:25 ` Jerome Lovy
2006-11-16 4:26 ` Theodore Tso
2006-11-16 11:50 ` Andreas Ericsson
2006-11-16 16:30 ` Linus Torvalds
2006-11-16 17:01 ` Carl Worth
2006-11-16 17:30 ` Linus Torvalds
2006-11-16 17:44 ` Sean
2006-11-16 1:40 ` Anand Kumria
2006-11-15 19:32 ` Junio C Hamano
2006-11-16 1:14 ` Theodore Tso
2006-11-16 4:21 ` Junio C Hamano
2006-11-16 11:34 ` Alexandre Julliard
2006-11-16 14:01 ` Petr Baudis
2006-11-16 15:48 ` Alexandre Julliard
2006-11-17 13:32 ` Jakub Narebski
2006-11-17 16:49 ` Alexandre Julliard
2006-11-17 17:41 ` Jakub Narebski
2006-11-16 16:07 ` Theodore Tso
2006-11-16 16:49 ` Theodore Tso
2006-11-22 23:21 ` Sanjoy Mahajan
2006-11-24 11:29 ` Jakub Narebski
2006-11-16 1:20 ` Han-Wen Nienhuys
2006-11-16 1:53 ` Jakub Narebski
2006-11-16 2:03 ` Junio C Hamano
2006-11-16 2:30 ` Han-Wen Nienhuys
2006-11-16 3:27 ` Junio C Hamano
2006-11-16 3:35 ` Junio C Hamano
2006-11-16 4:07 ` Junio C Hamano
2006-11-16 3:12 ` Linus Torvalds
2006-11-16 10:31 ` Junio C Hamano
2006-11-16 10:45 ` Han-Wen Nienhuys
2006-11-16 11:11 ` Junio C Hamano
2006-11-16 11:47 ` Junio C Hamano
2006-11-20 19:44 ` Horst H. von Brand
2006-11-20 19:46 ` Shawn Pearce
2006-11-20 20:02 ` Jakub Narebski
2006-11-16 13:03 ` Han-Wen Nienhuys
2006-11-16 13:11 ` Han-Wen Nienhuys
2006-11-17 13:25 ` Jakub Narebski
2006-11-24 12:26 ` Han-Wen Nienhuys
2006-11-24 12:41 ` Jakub Narebski
2006-12-05 22:42 ` Johannes Schindelin
2006-12-05 22:58 ` Junio C Hamano
2007-02-23 0:35 ` [PATCH for "next"] pretty-formats: add 'format:<string>' Johannes Schindelin
2007-02-23 1:03 ` Han-Wen Nienhuys
2007-02-23 1:07 ` Johannes Schindelin
2007-02-23 19:53 ` Robin Rosenberg
2007-02-24 1:25 ` Johannes Schindelin
2007-02-23 6:21 ` Junio C Hamano
2007-02-23 11:48 ` Johannes Schindelin
2007-02-23 18:30 ` Junio C Hamano
2007-02-23 18:38 ` Johannes Schindelin
2006-11-16 16:23 ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 16:42 ` Han-Wen Nienhuys
2006-11-16 17:17 ` Linus Torvalds
2006-11-16 17:40 ` multi-project repos (was Re: Cleaning up git user-interface warts) Han-Wen Nienhuys
2006-11-16 18:21 ` Linus Torvalds
2006-11-16 18:33 ` multi-project repos Junio C Hamano
2006-11-16 19:01 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-17 16:26 ` Shawn Pearce
2006-11-17 16:45 ` Linus Torvalds
2006-11-17 16:51 ` Carl Worth
2006-11-17 17:08 ` Shawn Pearce
2006-11-17 16:46 ` Carl Worth
2006-11-17 17:15 ` Shawn Pearce
2006-11-17 17:50 ` Marko Macek
2006-11-17 20:24 ` multi-project repos Junio C Hamano
2006-11-17 17:39 ` Junio C Hamano
2006-11-18 6:02 ` Shawn Pearce
2006-11-18 7:31 ` Junio C Hamano
2006-11-18 7:45 ` Shawn Pearce
2006-11-16 22:21 ` multi-project repos (was Re: Cleaning up git user-interface warts) Johannes Schindelin
2006-11-16 22:44 ` multi-project repos Junio C Hamano
2006-11-17 0:29 ` Johannes Schindelin
2006-11-16 22:49 ` multi-project repos (was Re: Cleaning up git user-interface warts) Linus Torvalds
2006-11-16 23:08 ` Linus Torvalds
2006-11-16 23:36 ` Johannes Schindelin
2006-11-17 0:49 ` Linus Torvalds
2006-11-17 1:08 ` Carl Worth
2006-11-17 1:22 ` Johannes Schindelin
2006-11-17 1:52 ` Petr Baudis
2006-11-17 2:16 ` Johannes Schindelin
2006-11-16 23:40 ` Han-Wen Nienhuys
2006-11-16 23:32 ` Han-Wen Nienhuys
2006-11-17 12:53 ` Jakub Narebski
2006-11-16 17:57 ` Cleaning up git user-interface warts Linus Torvalds
2006-11-16 18:27 ` Junio C Hamano
2006-11-16 18:28 ` Linus Torvalds
2006-11-16 19:47 ` Junio C Hamano
2006-11-16 19:53 ` Linus Torvalds
2006-11-16 18:13 ` Carl Worth
2006-11-16 23:00 ` Johannes Schindelin
2006-11-16 23:22 ` Linus Torvalds
2006-11-17 0:05 ` Han-Wen Nienhuys
2006-11-17 0:13 ` Junio C Hamano
2006-11-17 0:27 ` Han-Wen Nienhuys
2006-11-17 0:35 ` Petr Baudis
2006-11-17 0:37 ` Carl Worth
2006-11-17 1:25 ` Carl Worth
2006-11-17 0:39 ` Linus Torvalds
2006-11-17 0:52 ` Han-Wen Nienhuys
2006-11-17 1:34 ` Michael K. Edwards
2006-11-17 6:42 ` Michael K. Edwards
2006-11-17 7:32 ` Junio C Hamano
2006-11-18 1:24 ` Michael K. Edwards
2006-11-17 12:25 ` Jakub Narebski
2006-11-23 2:52 ` Horst H. von Brand
2006-11-16 4:30 ` Petr Baudis
2006-11-15 20:12 ` Petr Baudis
2006-11-15 20:26 ` Nicolas Pitre
2006-11-15 20:50 ` Linus Torvalds
2006-11-15 21:18 ` Nicolas Pitre
2006-11-16 1:51 ` Anand Kumria
2006-11-14 22:36 ` Junio C Hamano
2006-11-14 22:50 ` Junio C Hamano
2006-11-15 4:32 ` Nicolas Pitre
2006-11-15 5:35 ` Junio C Hamano
2006-11-15 6:18 ` Shawn Pearce
2006-11-15 6:30 ` Junio C Hamano
2006-11-15 14:01 ` Johannes Schindelin
2006-11-15 15:03 ` Sean
2006-11-15 15:10 ` Nicolas Pitre
2006-11-15 18:16 ` Junio C Hamano
2006-11-15 19:02 ` Andy Parkins
2006-11-15 19:41 ` Junio C Hamano
2006-11-15 20:15 ` Nicolas Pitre
2006-11-15 20:19 ` Carl Worth
2006-11-15 21:13 ` Junio C Hamano
2006-11-15 22:36 ` Carl Worth
2006-11-16 3:21 ` Petr Baudis
2006-11-16 10:09 ` Robin Rosenberg
2006-11-16 13:46 ` Petr Baudis
2006-11-16 0:23 ` Han-Wen Nienhuys
2006-11-15 9:17 ` Andy Parkins
2006-11-15 9:59 ` Jakub Narebski
2006-11-15 10:33 ` Andy Parkins
2006-11-15 10:48 ` Karl Hasselström
2006-11-15 11:28 ` Andy Parkins
2006-11-15 15:41 ` Nicolas Pitre
2006-11-15 17:59 ` Junio C Hamano
2006-11-15 18:11 ` Nicolas Pitre
2006-11-16 13:21 ` Karl Hasselström
2006-11-18 11:09 ` Alan Chandler
2006-11-15 17:55 ` Junio C Hamano
2006-11-15 19:14 ` Andy Parkins
2006-11-16 3:53 ` Petr Baudis
2006-11-15 12:15 ` Andreas Ericsson
2006-11-15 12:31 ` Jakub Narebski
2006-11-16 13:58 ` Petr Baudis
2006-11-16 5:12 ` Petr Baudis
2006-11-16 10:45 ` Junio C Hamano
2006-11-16 13:43 ` Petr Baudis
2006-11-16 21:49 ` Junio C Hamano
2006-11-16 22:20 ` Petr Baudis
2006-11-17 1:49 ` Junio C Hamano
2006-11-17 0:11 ` Han-Wen Nienhuys
2006-11-18 7:59 ` Alan Chandler
2006-11-14 23:30 ` [PATCH] commit: Steer new users toward "git commit -a" rather than update-index Junio C Hamano
2005-07-27 10:01 Git 1.0 Synopis (Draft v2) Ryan Anderson
2005-07-27 22:13 ` Junio C Hamano
2005-07-29 8:27 ` Ryan Anderson
2005-07-29 8:29 ` Git 1.0 Synopis (Draft v3 Ryan Anderson
2005-07-29 10:58 ` Johannes Schindelin
2005-07-29 21:26 ` Sam Ravnborg
2005-07-31 22:18 ` Horst von Brand
2005-07-31 22:15 ` Horst von Brand
2005-08-01 13:21 ` Horst von Brand
2005-08-15 4:55 ` Git 1.0 Synopis (Draft v4) Ryan Anderson
2005-08-15 5:09 ` Ryan Anderson
2005-08-15 5:19 ` Junio C Hamano
2005-08-15 6:58 ` Ryan Anderson
2005-08-15 7:17 ` Junio C Hamano
2005-08-15 8:02 ` Ryan Anderson
2005-08-15 8:17 ` Junio C Hamano
2005-08-15 18:59 ` Daniel Barkalow
2005-08-16 7:28 ` Junio C Hamano
2005-08-16 10:03 ` Johannes Schindelin
2005-08-16 10:14 ` Dongsheng Song
2005-08-16 10:17 ` about git server & permissions Dongsheng Song
2005-08-16 15:31 ` Git 1.0 Synopis (Draft v4) Johannes Schindelin
2005-08-16 15:47 ` Daniel Barkalow
2005-08-16 15:39 ` Daniel Barkalow
2005-08-16 19:41 ` Horst von Brand
2005-08-16 20:41 ` Johannes Schindelin
2005-08-18 9:27 ` Matthias Urlichs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).