Fix bugs in git-rebase wrt rebasing another branch than
the current HEAD, rebasing with a dirty working dir,
and rebasing a proper decendant of the target branch.
[jc: with a bit of hand-merging]
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An isolated developer could have a local-only e-mail, which will
be stripped out by mailinfo because it lacks '@'. Define a
fallback parser to accomodate that.
At the same time, reject authorless patch in git-am.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching to another branch and rebasing it in a one-go, it
failed to update the variable that holds the branch head, and
did not detect fast-forward situation correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recommend git over ssh direct to master.kernel.org, instead of
going over rsync to public machines, since this is meant to be a
procedure for kernel subsystem maintainers.
Also fix an obvious typo.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There were some problems with the usage message clean-up patch
series. I hadn't realised that subdirectory aware scripts can't source
git-sh-setup. I propose that we change this and let the scripts which
are subdirectory aware set a variable, SUBDIRECTORY_OK, before they
source git-sh-setup.
The scripts will also set USAGE and possibly LONG_USAGE before they
source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE.
If we go this way it's easy to catch --help in git-sh-setup, print the
(long) usage message to stdout and exit cleanly. git-sh-setup can
define a 'usage' shell function which can be called by the scripts to
print the short usage string to stderr and exit non-cleanly. It will
also be easy to change $0 to basename $0 or something else, if would
like to do that sometime in the future.
What follows is a patch to convert a couple of the commands to this
style. If it's ok with everyone to do it this way I will convert the
rest of the scripts too.
[jc: thrown in to proposed updates queue for comments.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows git-am to accept single-message files as well as mboxes.
Unlike the previous version, this one doesn't need to be explicitly told
which one it is; rather, it looks to see if the first line is a From
line and uses it to select mbox mode or not.
I moved the logic to do all this into git-mailsplit, which got a new
user interface as result, although the old interface is still available
for backwards compatibility.
[jc: applied with two obvious fixes.]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Talk about the following as well:
* git fetch --tags
* Use of "git push" as a one-man distributed development vehicle.
* Show example of remotes file for pulling and pushing.
* Annotate git-shell setup.
* Using Carl's update hook in a CVS-style shared repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In case some refs couldn't be pushed out due to an error (mostly the
not-a-proper-subset error), make git-send-pack exit with non-zero status
after the push is over (that is, it still tries to push out the rest
of the refs).
[jc: I adjusted a test for this change.]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Although "git-merge" is advertised as the end-user level command
(instead of being a "git-pull" backend), it was not prepared to
take tag objects that point at commits and barfed when fed one.
Sanitize the input while we validate them, for which we already
have a loop.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When clone-pack has trouble with the remote, it dies unfriendly
"EOF" error message. We cannot tell the reason why it failed
from the local end; it could be that the repository did not
exist, or configured not to serve over git-daemon, or a network
failure. At least, saying clone-pack failed makes it a bit more
meaningful.
I am not convinced yet that removing the newly created directory
is the right thing to do, so this commit leaves the new
directory behind.
Reported by Sam Ravnborg.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The initial section of tutorial was too heavy on internal
workings for the first-time readers, so rewrite the introductory
section of git(7) to start with "not learning core git commands"
section and refer them to README to grasp the basic concepts,
then Everyday to give overview with task/role oriented examples
for minimum set of commands, and finally the tutorial.
Also add to existing note in the tutorial that many too
technical descriptions can be skipped by a casual reader.
I initially started to review the tutorial, with the objective
of ripping out the detailed technical information altogether,
but I found that the level of details in the initial couple of
sections that talk about refs and the object database in a
hands-on fashion was about rigth, and left all of them there. I
feel that reading about fsck-index and repack is too abstract
without being aware of these directories and files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow we checked only one side and not the other. By checking
the filesize upfront, we can bypass generating delta
unnecessarily.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Delta computation with an empty blob used to punt and returned NULL.
This commit allows creation with empty blob; all combination of
empty->empty, empty->something, and something->empty are allowed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test kicks in only if you built test-delta executable, and
makes sure that the basic delta routine is working properly even
on empty files.
This commit is to make sure we have a test to catch the
breakage. The delitifier code is still broken, which will be
fixed with the next commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This bug caused Darrin Thompson to notice that our deltifier was
half broken and punting on an empty blob.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
This adds a couple of tests to cover the following renaming
merge cases:
- one side renames and the other side does not, with and without
content conflicts.
- both side rename to the same path, with and without content
conflicts.
The test setup also prepares a case in which both side rename to
different destination, but currently the code collapses these
destination paths and removes the original path, which may be
wrong. The outcome of this case is not checked by the tests in
this round.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fredrik points out there is a useful wrapper runProgram() used
everywhere that we can use to feed input into subprocess. Use
it to catch errors from the subprocess; it is a good cleanup as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does two things.
- When one branch renamed and the other branch did not, the
resulting half-merged file in the working tree used to swap
branches around and showed as if renaming side was "ours".
This was confusing and inconsistent (even though the conflict
markers were marked with branch names, it was not a good
enough excuse). This changes the order of arguments to
mergeFile in such a case to make sure we always see "our"
change between <<< and ===, and "their" change between ===
and >>>.
- When both branches renamed to the same path, and when one
branch renamed and the other branch did not, we attempt
mergeFile. When this automerge conflicted, we used to
collapse the index. Now we use update-index --index-info
to inject higher stage entries to leave the index in unmerged
state for these two cases.
What this still does _not_ do is to inject unmerged state into
the index when the structural changes conflict. I have not
thought things through what to do in each case yet, but the
cases this commit cover are the most common ones, so this would
be a good start.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This would help sorting by subject in MUA work saner even though
MUA is too dumb to attempt sorting numbered subjects sanely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
People seem to be getting test failure from t6021 not becuase
git is faulty but because they forgot to install "merge". Check
this and other trivial pilot errors in the first test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to support getting data into git with scripts, this adds a
--stdin option to git-hash-object, which will make it read from stdin.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a stupid bug I introduced when splitting the
accurate and fast changeset appliers.
Also, remove an old debugging statement I added
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
This fixes the case (that worked originally in Martin's version)
where the only new/modified files are Arch control files.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
