git-gui: Remove 'Allow Partially Added Files' option.

Now that we take the approach of core Git where we allow the user to
stage their changes directly into the index all of the time there is
absolutely no reason to have the Allow Partially Added Files option,
nor is there a reason or desire to default that option to false.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use borders on text fields in branch dialog.

On Mac OS X wish does not draw borders around text fields, making the
field look like its not even there until the user focuses into it. I
don't know the Mac OS X UI standards very well, but that just seems
wrong.  Other applications (e.g. Terminal.app) show their input boxes
with a sunken relief, so we should do the same.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow creating branches from tracking heads.

Sometimes you want to create a branch from a remote tracking branch.
Needing to enter it in the revision expression field is very annoying,
so instead let the user select it from a list of known tracking branches.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow users to delete branches merged upstream.

Most of the time when you are deleting branches you want to delete
those which have been merged into your upstream source.  Typically
that means it has been merged into the tip commit of some tracking
branch, and the current branch (or any other head) doesn't matter.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Implemented local branch deletion.

Users can now delete a local branch by selecting from a list of
available branches.  The list automatically does not include
the current branch, as deleting the current branch could be quite
dangerous and should not be supported.

The user may also chose to have us verify the branches are fully
merged into another branch before deleting them.  By default we
select the current branch, matching 'git branch -d' behavior,
but the user could also select any other local branch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Bind M1-N to create branch.

Creating branches is a common enough activity within a Git project
that we probably should give it a keyboard accelerator.  N is not
currently used and seems reasonable to stand for "New Branch". To
bad our menu calls it create.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Implemented create branch GUI.

Users may now create new branches by activating the Branch->Create menu
item.  This opens a dialog which lets the user enter the new branch
name and select the starting revision for the new branch.

For the starting revision we allow the user to either select from a
list of known heads (aka local branches) or to enter an arbitrary
SHA1 expression.  For either creation technique we run the starting
revision through rev-parse to verify it is valid before trying to
create the ref with update-ref.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Pad the cancel/save buttons in the options window.

It looks horrible to have the cancel and save buttons wedged up against
each other in our options dialog.  Therefore toss a 5 pixel pad between
them.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Only permit selection in one list at a time.

Now that our lists represent more defined states it no longer makes any
sense to permit a user to make selections from both lists at once, as
the each available operation acts only on files whose status corresponds
to only one of the lists.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Simplify printing of index info to update-index.

During unstaging we can simplify the way we perform the output by
combining our four puts into a single call.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor the add to commit state filters.

The list of states which are valid for update-index were a little
too verbose and fed a few too many cases to the program.  We can
do better with less lines of code by using more pattern matching,
and since we already were globbing here there's little change in
runtime cost.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor the revert (aka checkout-index) implementation.

We can revert any file which has a valid stage 0 (is not unmerged)
and which is has a working directory status of M or D.  This vastly
simplifies our pattern matching on file status when building up the
list of files to perform a checkout-index against.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Add or unstage based on the specific icon used.

Rather than relying on the file state and just inverting it, we should
look at which file icon the user clicked on.  If they clicked on the
one in the "Changes To Be Committed" list then they want to unstage
the file.  If they clicked on the icon in the "Changed But Not Updated"
list then they want to add the file to the commit.  This should be much
more reliable about capturing the user's intent then looking at the file
state.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor add/remove proc names to align with reality.

Now that core Git refers to resetting paths in the index as "unstaging"
the paths we should do the same in git-gui, both internally in our code
and also within the menu action name.  The same follows for our staging
logic, as core Git refers to this as 'add'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup state descriptions.

Updated the state descriptions for individual file states to try and
make them more closely align with what git-runstatus might display.
This way a user who is reading Git documentation will be less confused
by our descriptions.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove invalid DM state.

The DM state cannot really happen.  Its implying that the file has
been deleted in the index, but the file in the working directory has
been modified relative to the file in the index.  This is complete
nonsense, the file doesn't exist in the index for it to be different
against!

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct DD file state to be only D_.

Apparently my earlier suspicion that the file state DD was a bug was
correct.  A file which has been deleted from the working directory and
from the index will always get the state of D_ during a rescan.  Thus
the only valid state for this to have is D_.  We should always use only
D_ internally during our state changes.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Convert UI to use 'staged for commit' interface.

This is a rather drastic change to the git-gui user interface, but it
doesn't really look any different yet.  I've taken the two lists and
converted them to being "changes to be committed" and "changed but
not updated".  These lists correspond to the same lists output by
git-runstatus based on how files differ in the HEAD<->index and the
index<->working directory comparsions it performs.

This change is meant to correlate with the change in Git 1.5.0 where
we have brought the index more into the foreground and are trying to
teach users to make use of it as part of their daily operations.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Start file status display refactoring.

I'm going to refactor the way file status information gets displayed
so it more closely aligns with the way 'git-runstatus' displays the
differences between HEAD<->index and index<->working directory.  To
that end the other file list is going to be changed to be the working
directory difference.  So this change renames it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the directory we are entering during startup.

If the user has many git-gui icons it may be confusing when they
start one which git-gui is still coming up.  So on the windows
systems we now include an echo statement which displays the full
pathname of the working directory we are trying to enter into.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Make the gitk starting message match our usual format.

Because we usually say "Operation... please wait..." we should do
the same thing when starting gitk.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow [gitdir ...] to act as [file join [gitdir] ...].

Because it is such a common idiom to use [gitdir] along with [file join]
to locate the path of an item within the .git directory of the current
repository we might as well allow gitdir to act as a wrapper for the
file join operation.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup usage of gitdir global variable.

The gitdir global variable is essentially read-only, and is used rather
frequently.  So are appname and reponame.  Needing to constantly declare
'global appname' just so we can access the value as $appname is downright
annoying and redundant.  So instead I'm declaring these as procedures and
changing all uses to invoke the procedure rather than access the global
directly.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor reponame computation.

We use reponame in a number of locations, and every time its always the
same value.  Instead of computing this multiple times with code that was
copied and pasted around we can compute it once immediately after the
global gitdir has been computed and set.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Suggest when running 'git gc' may be worthwhile.

Users often forget to repack their object database, then start to
complain about how slow it is to perform common operations after
they have collected thousands of loose objects in their objects
directory.  A simple repack usually restores performance.

During startup git-gui now asks git-count-objects how many loose
objects exist, and if this number exceeds a hardcoded threshold
we suggest that the user compress the database (aka run 'git gc')
at this time.  I've hardcoded this to 2000 objects on non-Windows
systems as there the filesystems tend to handle the ~8 objects
per directory just fine.  On Windows NTFS and FAT are just so slow
that we really start to lag when more than 200 loose objects exist,
so the hardcoded threshold is much lower there.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't offer my miga hack if its configuration file isn't present.

I really hate that I have this specialized hack within git-gui, but
its here.  The hack shouldn't be offered unless miga's required .pvcsrc
file is in the top level of the repository's working directory.  If
this file is missing miga will fail to startup properly, and the user
cannot wouldn't be able to use it within this directory.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow the user to copy the version data to the clipboard.

If a user wants to report an issue they will likely want to include
the version number with their issue report.  This may be difficult
to enter if the version number includes an abbreviated commit SHA1
on the end of it.  So we now give the user a context menu option
on the version box which allows them to copy all of the relevant
version data to the clipboard, ready for pasting into a report.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Ensure version number is always current.

I'm stealing the exact logic used by core Git within its own Makefile to
setup the version number within scripts and executables.  This way we
can be sure that the version number is always updated after a commit,
and that the version number also reflects when it is coming from a dirty
working directory (and is thus pretty worthless).

I've cleaned up some of the version display code in the about dialog too.
There were simply too many blank lines in the bottom section where we
showed the version data.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the full GPL copyright notice in about dialog.

We're a true GPL program, and we're interactive.  We should show the
entire GPL notice and disclaimer of warranty in our about dialog upon
request by the user, as well as include it in the header of our source.
Perhaps overkill, but is recommended by our license.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the git-gui version in the Help->About dialog.

Now that we know what version git-gui is, the about dialog should
display it to the end-user.  This way users can find out what version
they have before they report a problem or request a feature.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Modified makefile to embed version into git-gui script.

We want to embed the version of git-gui directly into the script file,
so that we can display it properly in the about dialog.  Consequently
I've refactored the Makefile process to act like the one in core git.git
with regards to shell scripts, allowing git-gui to be constructed by a
sed replacement performed on git-gui.sh.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Hide the ugly bash command line from the windows desktop icon.

The user really doesn't need to see the technical details of how we
launch git-gui from within their "desktop icon".  Instead we should hide
the command line from being displayed when the icon launches by putting
@ at the start of the line.  If they really need to see the command we
are running they can edit the batch file.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Change more 'include' language to 'add'.

I just found a whole slew of places where we still were using the term
'include' rather than 'add' to refer to the act of updating the index
with modifications from the working directory.  To be consistent with
all Git documentation and command line tools, these should be 'add'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Work around odd cygpath bug on Windows.

There appears to be a bug on one of my test systems where cygpath with
the --long-name option is generating a corrupt string that does not
actually refer to sh.exe.  This breaks any desktop icon created by
git-gui as the executable we are trying to invoke does not exist.
Since Cygwin is typically installed as C:\cygwin long path names is
probably not actually necessary to link to the shell.

I also added a small echo to the start of the icon script, as it can
take one of my test systems several seconds to startup git-gui.  This
way the user knows we're starting git-gui, and was politely asked to
wait for the action to complete.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct wording of the revert confirmation dialog.

We no longer describe updating the index as including changes, as we
now use the add notation used by core Git's command line tools.  So
its confusing to be talking about unincluded changes within the revert
dialog.  Instead we should used language like 'unadded changes'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Corrected behavior of deleted (but existing in HEAD) files.

Apparently I did not account for the D_ file state.  This can occur when
a file has been marked for deletion by deleting it from the index, and
the file also does not exist in the working directory.  Typically this
happens when the user deletes the file, hits Rescan, then includes the
missing file in the commit, then hits Rescan again.  We don't find the
file in the working directory but its been removed in the index, so the
state becomes D_.

This state should be identical with DD.  I'm not entirely sure why DD
occurs sometimes and D_ others, it would seem like D_ is the state that
should be happening instead of DD, leading me to believe there is a quirk
in git-gui's state manipulation code.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Run git-gc rather than git-repack.

Now that git 1.5.0-rc1 and later has a 'git gc' command which performs
all important repository management activites (including reflog pruning,
repacking local objects, unnecessary loose object pruning and rerere cache
expiration) we should run 'gc' when the user wants us to cleanup their
object database for them.

I think the name 'gc' is horrible for a GUI application like git-gui,
so I'm labeling the menu action 'Compress Database' instead.  Hopefully
this will provide some clue to the user about what the action does.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show all fetched branches for remote pulls.

Loop through every remote.<name>.fetch entry and add it as a valid
option in the Pull menu.  This way users can pull any remote branch
that they track, without needing to leave the gui.  Its a rather crude
work around for not having a full merge interface.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Created very crude Tools menu, to support miga.

In one particular case I have a tool called 'miga' which users may need
to invoke on their repository.  This is a homegrown tool which is not
(and should be) part of git-gui, but I still want to be able to run it
from within the gui.

Right now I'm taking a shortcut and adding it to the Tools menu if
we are not on Mac OS X and the support script used to launch the tool
exists in the local filesystem.  This is nothing but a complete and
utter hack.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Reworded 'Include' to 'Add' to match core Git.

Now that git-add is a first class citizen in core Git (Nico's 366bfcb6)
users may start to expect the term 'add' to refer to the act of including
a file's changes into a commit.  So I'm replacing all uses of the term
'Include' in the UI with 'Add'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Teach revision machinery about --reverse

The option --reverse reverses the order of the commits.

[jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.]

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

GIT v1.5.0-rc2

Signed-off-by: Junio C Hamano <junkio@cox.net>

prune: --grace=time

This option gives grace period to objects that are unreachable
from the refs from getting pruned.

The default value is 24 hours and may be changed using
gc.prunegrace.

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

--walk-reflogs: do not crash with cyclic reflog ancestry

Since you can reset --hard to any revision you already had, when
traversing the reflog ancestry, we may not free() the commit buffer.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

--walk-reflogs: actually find the right commit by date.

Embarassing thinko.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

Fix --walk-reflog with --pretty=oneline

Now, "git log --abbrev-commit --pretty=o --walk-reflogs HEAD" is
reasonably pleasant to use.

Signed-off-by: Junio C Hamano <junkio@cox.net>

reflog-walk: build fixes

Dependency on reflog-walk.h was missing in the Makefile, and
reflog-walk.c did not even include it.

Signed-off-by: Junio C Hamano <junkio@cox.net>

log --walk-reflog: documentation

Signed-off-by: Junio C Hamano <junkio@cox.net>

--walk-reflogs: disallow uninteresting commits

Do not allow uninteresting commits with --walk-reflogs, since it is
not clear what should be shown in these cases:

$ git log --walk-reflogs master..next
$ git log --walk-reflogs ^master

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

Teach the revision walker to walk by reflogs with --walk-reflogs

When called with "--walk-reflogs", as long as there are reflogs
available, the walker will take this information into account, rather
than the parent information in the commit object.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-rebase: allow rebasing a detached HEAD.

Signed-off-by: Junio C Hamano <junkio@cox.net>

branch -f: no reason to forbid updating the current branch in a bare repo.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-tag -d: allow deleting multiple tags at once.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Do not verify filenames in a bare repository

For example, it makes no sense to check the presence of a file
named "HEAD" when calling "git log HEAD" in a bare repository.

Noticed by Han-Wen Nienhuys.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

Stop ignoring Documentation/README

We do not copy this file from elsewhere anymore.

Signed-off-by: Junio C Hamano <junkio@cox.net>

apply --cached: fix crash in subdirectory

The static variable "prefix" was shadowed by an unused parameter
of the same name. In case of execution in a subdirectory, the
static variable was accessed, leading to a crash.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

show-branch --reflog: fix show_date() call

Not passing tz to show_date() is not a fix.

Signed-off-by: Junio C Hamano <junkio@cox.net>

show_date(): fix relative dates

We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970,
00:00:00 GMT) to the function. So there is no need to "fix" the
timestamp according to the timezone.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

user-manual: add "quick start" as chapter 1

Add a "quick start" guide, modelled after Mercurial's, as the
first chapter.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

show-branch --reflog: tighten input validation.

Signed-off-by: Junio C Hamano <junkio@cox.net>

show-branch --reflog: show the reflog message at the top.

This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.

You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>.  <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').

Here is a sample output (with --list option):

  $ git show-branch --reflog=10 --list jc/show-reflog
    [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
    [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
    [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
    [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use

This shows what I did more cleanly:

  $ git show-branch --reflog=10 jc/show-reflog
  ! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
   ! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    ! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
     ! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
      ! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
       ! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
        ! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
         ! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
          ! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
           ! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
  ----------
  +          [jc/show-reflog@{0}] show-branch --reflog: show the reflog
    +        [jc/show-reflog@{2}] show-branch --reflog: show the reflog
   +++       [jc/show-reflog@{1}] show-branch --reflog: show the reflog
  +++++      [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
       +     [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
        +    [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
         +   [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
           + [jc/show-reflog@{9}] show-branch --reflog: use updated rea
           + [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
           + [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
           + [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
  ++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM

At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).

I first saved them with "format-patch -4", and then did a reset
at @{8}.  At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent).  I did not like the
log message, so I amended again at @{5}.

Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it).  Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Extend read_ref_at() to be usable from places other than sha1_name.

You can pass an extra argument to the function to receive the
reflog message information.  Also when the log does not go back
beyond the point the user asked, the cut-off time and count are
given back to the caller for emitting the error messages as
appropriately.

We could later add configuration for get_sha1_basic() to make it
an error instead of it being just a warning.

Signed-off-by: Junio C Hamano <junkio@cox.net>

dwim_ref(): Separate name-to-ref DWIM code out.

I'll be using this in another function to figure out what to
pass to resolve_ref().

Signed-off-by: Junio C Hamano <junkio@cox.net>

config_set_multivar(): disallow newlines in keys

This will no longer work:

$ git repo-config 'key.with
newline' some-value

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

rename --exec to --receive-pack for push and send-pack

For now it's just to get a more descriptive name.  Later we might update the
push protocol to run more than one program on the other end.  Moreover this
matches better the corresponding config option remote.<name>. receivepack.

--exec continues to work

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

make --exec=... option to git-push configurable

Having to specify git push --exec=... is annoying if you cannot have
git-receivepack in your PATH on the remote side (or don't want to).

This introduces the config item remote.<name>.receivepack to override
the default value (which is "git-receive-pack").

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Update documentation of fetch-pack, push and send-pack

add all supported options to Documentation/git-....txt and the usage strings.

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/git.txt: command re-classification

This adds two new classes (pure-helpers and "Interacting with
Others") to the command list in the main manual page.  The
latter class is primarily about foreign SCM interface and is
placed before low-level (plumbing) commands.

Also it promotes a handful commands to mainporcelain category
while demoting some others.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: generated cmds-*.txt does not depend on git.txt

Pointed out by Santi.

Signed-off-by: Junio C Hamano <junkio@cox.net>

refs.c::read_ref_at(): fix bogus munmap() call.

The code uses mmap() to read reflog data, but moves the pointer around
while reading, and uses that updated pointer in the call to munmap().

Signed-off-by: Junio C Hamano <junkio@cox.net>

for_each_reflog_ent: do not leak FILE *

The callback function can signal an early return by returning non-zero,
but the function leaked the FILE * opened on the reflog when doing so.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: Generate command lists.

This moves the source of the list of commands and categorization
to the end of Documentation/cmd-list.perl, so that re-categorization
and re-ordering would become easier to manage.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: sync git.txt command list and manual page title

Also reorders a handful entries to make each list sorted
alphabetically.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: move command list in git.txt into separate files.

Signed-off-by: Junio C Hamano <junkio@cox.net>

prune-packed: add -q to usage

Signed-off-by: Junio C Hamano <junkio@cox.net>

Document --ignore-if-in-upstream in git-format-patch

Signed-off-by: Junio C Hamano <junkio@cox.net>

Shell syntax fix in git-reset

Signed-off-by: Junio C Hamano <junkio@cox.net>

Use standard -t option for touch.

Non-GNU touch do not have the -d option to take free form
date strings.  The POSIX -t option should be more widespread.
For this to work, date needs to output YYYYMMDDHHMM.SS date strings.

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use fixed-size integers for .idx file I/O

This attempts to finish what Simon started in the previous commit.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Use fixed-size integers for the on-disk pack structure.

Plain integer types without a fixed size can vary between platforms.  Even
though all common platforms use 32-bit ints, there is no guarantee that
this won't change at some point.  Furthermore, specifying an integer type
with explicit size makes the definition of structures more obvious.

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Accept 'inline' file data in fast-import commit structure.

Its very annoying to need to specify the file content ahead of a
commit and use marks to connect the individual blobs to the commit's
file modification entry, especially if the frontend can't/won't
generate the blob SHA1s itself.  Instead it would much easier to
use if we can accept the blob data at the same time as we receive
each file_change line.

Now fast-import accepts 'inline' instead of a mark idnum or blob
SHA1 within the 'M' type file_change command.  If an inline is
detected the very next line must be a 'data n' command, supplying
the file data.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Reduce value duplication in t9300-fast-import.

It is error prone to list the value of each file twice, instead we
should list the value only once early in the script and reuse the
shell variable when we need to access it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Create test case for fast-import.

Now that its easier to craft test cases (thanks to 'data <<')
we should start to verify fast-import works as expected.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Support delimited data regions in fast-import.

During testing its nice to not have to feed the length of a data
chunk to the 'data' command of fast-import.  Instead we would
prefer to be able to establish a data chunk much like shell's <<
operator and use a line delimiter to denote the end of the input.

So now if a data command is started as 'data <<EOF' we will look
for a terminator line containing only the string EOF on that line.
Once found, we stop the data command.  Everything between the two
lines is used as the data value.

The 'data <<' syntax is slower than 'data n', as we don't know how
many bytes to expect and instead must grow our buffer on the fly.
It also has the problem that the frontend must use a string which
will not appear on a line by itself in the input, and the data
region will always end in an LF.  For these reasons real import
frontends are encouraged to continue to use _only_ 'data n'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Remove unnecessary options from fast-import.

The --objects command line option is rather unnecessary.  Internally
we allocate objects in 5000 unit blocks, ensuring that any sort
of malloc overhead is ammortized over the individual objects to
almost nothing.  Since most frontends don't know how many objects
they will need for a given import run (and its hard for them to
predict without just doing the run) we probably won't see anyone
using --objects.  Further since there's really no major benefit
to using the option, most frontends won't even bother supplying
it even if they could estimate the number of objects.  So I'm
removing it.

The --max-objects-per-pack option was probably a mistake to even
have added in the first place.  The packfile format is limited
to 4 GiB today; given that objects need at least 3 bytes of data
(and probably need even more) there's no way we are going to exceed
the limit of 1<<32-1 objects before we reach the file size limit.
So I'm removing it (to slightly reduce the complexity of the code)
before anyone gets any wise ideas and tries to use it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Use fixed-size integers when writing out the index in fast-import.

Currently the pack .idx file format uses 32-bit unsigned integers
for the fan-out table and the object offsets.  We had previously
defined these as 'unsigned int', but not every system will define
that type to be a 32 bit value.  To ensure maximum portability we
should always use 'uint32_t'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Always use struct pack_header for pack header in fast-import.

Previously we were using 'unsigned int' to update the hdr_entries
field of the pack header after the file had been completed and
was being hashed.  This may not be 32 bits on all platforms.
Instead we want to always uint32_t.

I'm actually cheating here by just using the pack_header like the
rest of Git and letting the struct definition declare the correct
type.  Right now that field is still 'unsigned int' (wrong) but a
pending change submitted by Simon 'corecode' Schubert changes it
to uint32_t.  After that change is merged in fast-import will do
the right thing all of the time.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-format-patch: the default suffix is now .patch, not .txt

Editors often give easier handling of patch files if the
filename ends with .patch, so use it instead of .txt.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-format-patch: make --binary on by default

It does not make much sense to generate a patch that cannot be
applied.  If --text is specified on the command line it still
takes precedence.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Add --summary to git-format-patch by default

This adds --summary output in addition to the --stat to the
output from git-format-patch by default.

I think additions, removals and filemode changes are rare but
notable events and always showing it makes sense.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-format-patch -3

This teaches "git-format-patch" to honor the --max-count
parameter revision traversal machinery takes, so that you can
say "git-format-patch -3" to process the three topmost commits
from the current HEAD (or "git-format-patch -2 topic" to name a
specific branch).

Signed-off-by: Junio C Hamano <junkio@cox.net>

Document pack .idx file format upgrade strategy.

Way back when Junio developed the 64 bit index topic he came up
with a means of changing the .idx file format so that older Git
clients would recognize that they don't understand the file and
refuse to read it, while newer clients could tell the difference
between the old-style and new-style .idx files.  Unfortunately
this wasn't recorded anywhere.

This change documents how we might go about changing the .idx
file format by using a special signature in the first four bytes.
Credit (and possible blame) goes completely to Junio for thinking
up this technique.

The change also modifies the error message of the current Git code
so that users get a recommendation to upgrade their Git software
should this version or later encounter a new-style .idx which it
cannot process.  We already do this for the .pack files, but since
we usually process the .idx files first its important that these
files are recognized and encourage an upgrade.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Refer users to git-rev-parse for revision specification syntax.

The revision specification syntax (sometimes referred to as
SHA1-expressions) is accepted almost everywhere in Git by
almost every tool.  Unfortunately it is only documented in
git-rev-parse.txt, and most users don't know to look there.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Document the master@{n} reflog query syntax.

In ab2a1a32 Junio improved the reflog query logic to support
obtaining the n-th prior value of a ref, but this was never
documented in git-rev-parse.  Now it is.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/git-parse-remote.txt: we deal with config vars as well

... but we never documented it.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: m can be relative in "git-blame -Ln,m"

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: suggest corresponding Porcelain-level in plumbing docs.

Instead of keeping the confused end user reading low-level
documentation, suggest the higher level commands that implement
what the user may want to do using them upfront.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/git-resolve: deprecated.

Signed-off-by: Junio C Hamano <junkio@cox.net>

sanitize content of README file

Current README content is way too esoteric for someone looking at GIT
for the first time. Instead it should provide a quick summary of what
GIT is with a few pointers to other resources.

The bulk of the previous README content is moved to
Documentation/core-intro.txt.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-format-patch: do not crash with format.headers without value.

An incorrect config file can say:

[format]
headers

and crash the parsing.

Signed-off-by: Junio C Hamano <junkio@cox.net>