Mostly making the formatted html prettier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 7adf1f15ebe074d4767df941817a6cf86d8e2533 commit)
Linus says:
I'm testing bisection to find a bug that causes my G5 to no longer boot,
and during the process have found this command line very nice:
gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)
it basically shows the state of bisection with the known bad commit as the
top, and cutting off all the good commits - so what you see are the
potential buggy commits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When testing bisection and using gitk to visualize the result, it was
obvious that the termination condition was broken.
We know what the bad entry is only when the bisection ends up telling us
to test the known-bad entry again.
Also, add a safety net: if somebody marks as good something that includes
the known-bad point, we now notice and complain, instead of writing an
empty revision to the new bisection branch.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we always prefixed refs/heads to the token given to "git fetch"
(and "git pull") as refspec. This was a mistake. Allow them to be
spelled like "master:refs/tags/paulus" to mean "I want to fetch the
master there and store it as my local "paulus" tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we resolve a merge between two branches, and it removes a file in the
current branch, we notify the person doing the resolve with a big nice
notice like
Removing xyzzy
which is all well and good.
HOWEVER, we also do this when the file was actually removed in the current
branch, and we're merging with another branch that didn't have it removed
(or, indeed, if the other branch _did_ have it removed, but the common
parent was far enough back that the file still existed in there).
And that just doesn't make sense. In that case we're not removing
anything: the file didn't exist in the branch we're merging into in the
first place. So the message just makes people nervous, and makes no sense.
This has been around forever, but I never bothered to do anything about
it.
Until now.
The trivial fix is to only talk about removing files if the file existed
in the branch we're merging into, but will not exist in the result.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes it may be handy to be able to edit messages that come
from somewhere other than an existing commit.
This makes 'git commit -F <file> -e' to start editor with the initial
log message contents taken from <file>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The original committer may have used validation criteria that is less
stricter than yours. You do not want to lose the changes even if they
are done in substandard way from your 'commit -v' verifier's point of
view.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Setting the wraplength to zero keeps the bird from trimming WS.
Signed-off-by: <gitzilla@gmail.com>
(cherry picked from 1d535d525d6a0ddddc3755065d721278bc5f0aff commit)
This originally came from Frank Sorenson, but with a bit of rework to
allow future enhancements without changing the external interface for
pack pruning part.
With the '-a' option, all objects in the current repository are packed
into a single pack. When the '-d' option is given at the same time,
existing packs that were made redundant by this round of repacking are
deleted.
Since we currently have only two repacking strategies, one with '-a'
(everything into one) and the other without '-a' (incrementally pack
only the unpacked ones), the '-d' option is meaningful only when used
with '-a'; it removes the packs existed before we did the "everything
into one" repacking. At least for now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Frank Sorenson <frank@tuxrocks.com>
(cherry picked from bfed505327e31221d8de796b3af880bad696b149 commit)
Earlier show-branch gave names only to commits reachable via first
parent ancestry chain. Change the naming code to name everybody.
The original idea was to stop at the first merge point in the
topological order, and --more=<n> to show commits until we show <n>
more extra merge points. However depending on the order of how we
discover the commits, it additionally showed parents of the <n>th
merge points, which was unnecessary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This attempts to minimally cope with a subset of MIME "features" often
seen in patches sent to our mailing lists. Namely:
- People's name spelled in characters outside ASCII (both on From:
header and the signed-off-by line).
- Content-transfer-encoding using quoted-printable (both in
multipart and non-multipart messages).
These MIME features are detected and decoded by "git mailinfo".
Optionally, with the '-u' flag, the output to .info and .msg is
transliterated from its original chaset to utf-8. This is to
encourage people to use utf8 in their commit messages for
interoperability.
Applymbox accepts additional flag '-u' which is passed to mailinfo.
Signed-off-by: Junio C Hamano / 濱野 純 <junkio@cox.net>
Now the rebase is rewritten to use git cherry-pick, there is no user
for that ancient script. I've checked Cogito and StGIT to make sure
they do not use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reverse patch application using "git apply" sometimes is too
rigid. Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.
Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree. Revert applies
the diff in reverse while cherry-pick applies it forward. They share
the same logic, just different messages and merge direction.
Rewrite "git rebase" using "git cherry-pick".
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts 6c5f9baa3b commit, whose
change breaks gcc-2.95.
Not that I ignore portability to compilers that are properly C99, but
keeping compilation with GCC working is more important, at least for
now. We would probably end up declaring with "name[1]" and teach the
allocator to subtract one if we really aimed for portability, but that
is left for later rounds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Explain that an asterisk will be displayed in front of the current
branch when you run `git branch' to see which are available.
Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- It does not matter how I read git list. What matters is that
I do not necessarily read everything on it.
- Talk a bit about how to use applymbox to check one's own
patches.
- Talk a bit about PGP signed patches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add some documentation.
Text taken from the the commit messages and the command sources.
Signed-off-by: <gitzilla@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a new test case for the scanning forwards and backwards for the
correct location to apply a patch fragment.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a test case for patches with multiple fragments.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Stop processing and return NULL if we encounter a '\n' character
before we have two matching names in the git header.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When there is non-empty $GIT_DIR/info/exclude file, use it along
with .gitignore per-directory exclude pattern files (which was
a convention agreed on the list while ago and is compatible with
Cogito) to generate a list of ignored files as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from d330948a5ff0df55c2f12627c0583b4e16f1ea4d commit)
When not working on "master" branch, remind the user at the beginning
of the status message, not at the end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the "git pull" command updates the branch head you are
currently on, before doing anything else, first update your
index file and the working tree contents to that of the new
branch head. Otherwise, the later resolving steps would think
your index file is attempting to revert the change between the
original head commit and the updated head commit.
It uses two-tree fast-forward form of "read-tree -m -u" to
prevent losing whatever local changes you may have in the
working tree to do this update. I think this would at least
make things safer (a lot safer), and prevent mistakes.
Also "git fetch" command is forbidden from fetching and fast
forwarding the current branch head unless --update-head-ok flag
is given. "git pull" passes the flag when it internally calls
"git fetch".
Signed-off-by: Junio C Hamano <junkio@cox.net>
