Using a stack of frames in the Starting Revision section of the new
branch dialog turned out to be a mess. The varying lengths of each
label caused the optionMenu widgets to be spread around the screen
at unaligned locations, making the interface very kludgy looking.
Now we layout the major sections of the branch dialog using grid
rather than pack, allowing these widgets to line up vertically in
a nice neat column. All extra space is given to column 1, which is
where we have located the text fields.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new branch name input box was showing up too close to the labelframe
border, it was basically right on top of it on Windows. This didn't
look right when compared to the Starting Revision's expression input
field, as that had a 5 pixel padding.
So I've put the new name input box into its own frame and padded that
frame by 5 pixels, making the UI more consistent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Correct unmerged file detection at commit time.
Its impossible to commit an index which has unmerged stages.
Unfortunately a bug in git-gui allowed the user to try to do exactly that,
as we broke out of our file scanning loop as soon as we found a valid AMD
index state. That's wrong, as the files are coming back from our array
in pseudo-random order; an unmerged file may get returned only after all
merged files.
I also noticed the grammer around here in our dialog boxes still used
the term 'include', so this has been updated to reflect current usage.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes you want to just force the diff to redisplay itself without
rescanning every file in the filesystem (as that can be very costly
on large projects and slow operating systems). Now you can force a
diff-only refresh from the context menu. Previously you could also
do this by reclicking on the file name in the UI, but it may not be
obvious to all users, having a context menu option makes it more
clear.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A prior commit tried to use the old index state for the old working
directory state during a UI refresh of a file. This caused files
which were being unstaged (and thus becoming unmodified) to drop
out of the working directory side of the display, at least until
the user performed a rescan to force the UI to redisplay everything.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Clear diff from viewer if the side changed.
If the user switches the currently shown file from one side of the UI
to the other then how its diff is presented would be different. And
leaving the old diff up is downright confusing.
Since the diff is probably not interesting to the user after the switch
we should just clear the diff viewer. This saves the user time, as they
won't need to wait for us to reload the diff.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We were not correctly setting the old state of an index display to
_ if the index was previously unmerged. This caused us to try and
update a U->M when resolving a merge conflict but we were unable to
do so as the icon did not exist in the index viewer. Tk did not
like being asked to modify an icon which was undefined.
Now we always transform both the old and the new states for both
sides (index and working directory) prior to updating the UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Improve diff --cc viewing for unmerged files.
Now that we are using 'git diff' to display unmerged working directory
files we are getting 'diff --cc' output rather than 'diff --combined'
output. Further the markers in the first two columns actually make
sense here, we shouldn't attempt to rewrite them to something else.
I've added 'diff --cc *' to the skip list in our diff viewer, as that
particular line is not very interesting to display.
I've completely refactored how we perform detection of the state of a
line during diff parsing; we now report an error message if we don't
understand the particular state of any given line. This way we know
if we aren't tagging something we maybe should have tagged in the UI.
I've also added special display of the standard conflict hunk markers
(<<<<<<<, =======, >>>>>>>). These are formatted without a patch op
as the patch op is always '+' or '++' (meaning the line has been added
relative to the committed state) and are displayed in orange bold text,
sort of like the @@ or @@@ marker line is at the start of each hunk.
In a 3 way merge diff hunks which came from our HEAD are shown with a
azure2 background, and hunks which came from the incoming MERGE_HEAD
are displayed with a 'light goldenrod yellow' background. This makes
the two different hunks clearly visible within the file. Hunks which
are ++ or -- (added or deleted relative to both parents) are shown
without any background at all.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a file has a merge conflict we want it to show up in the 'Changed
But Not Updated' file list rather than the 'Changes To Be Committed'
file list. This way the user can mostly ignore the left side (the
HEAD<->index comparsion) while resolving a merge and instead focus
on the merge conflicts, which are just shown on the right hand side.
This requires detecting the U state in the index side and drawing
it as though it were _, then forcing the working directory side to
have a U state. We have to delay this until presentation time as
we don't want to change our internal state data to be different
from what Git is telling us (I tried, the patch for that was ugly
and didn't work).
When showing a working directory diff and its a merge conflict we
don't want to use diff-files as this would wind up showing any
automatically merged hunks obtained from MERGE_HEAD in the diff.
These are not usually very interesting as they were completed by
the system. Instead we just want to see the conflicts. Fortunately
the diff porcelain-ish frontend (aka 'git diff') detects the case of
an unmerged file and generates a --cc diff against HEAD and MERGE_HEAD.
So we now force any working directory diff with an index state of 'U'
to go through that difference path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The combined diff format can be very confusing, especially to new users
who may not even be familiar with a standard two way diff format. So
for files which are already staged for commit and which are modifed in
the working directory we should show two different diffs, depending on
which side the user clicked on.
If the user clicks on the "Changes To Be Committed" side then we should
show them the PARENT<->index difference. This is the set of changes they
will actually commit.
If the user clicks on the "Changed But Not Updated" side we should show
them the index<->working directory difference. This is the set of changes
which will not be committed, as they have not been staged into the index.
This is especially useful when merging, as the "Changed But Not Updated"
files are the ones that need merge conflict resolution, and the diff here
is the conflict hunks and/or any evil merge created by the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now need to keep track of which side the current diff is for,
HEAD<->index or index<->working directory. Consequently we need
an additional "current diff" variable to tell us which side the
diff is for. Since this is really only necessary in reshow_diff
I'm going to declare a new global, rather than try to shove both
the path and the side into current_diff.
To keep things clear later on, I'm renaming current_diff to
current_diff_path. There is no functionality change in this
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Attempt to checkout the new branch after creation.
If the user asked us to checkout the branch after creating it then
we should try to do so. This may fail, especially right now since
branch switching from within git-gui is not supported.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its possible for the user to select a branch for the merge test
(while deleting branches) and also select that branch for deletion.
Doing so would have bypassed our merge check for that branch, as
a branch is always a strict subset of itself. So we will simply
skip over a branch and not delete it if that is the branch which
the user selected for the merge check.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Improve the branch delete confirmation dialogs.
If the user is deleting a branch which is fully merged into the
selected test branch we should not confirm the delete with them,
the fact that the branch is fully merged means we can recover the
branch and no work will be lost.
If a branch is not fully merged, we should warn the user about which
branch(es) that is and continue deleting those which are fully merged.
We should only delete a branch if the user disables the merge check,
and in that case we should confirm with the user that a delete should
occur as this may cause them to lose changes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The only reason the commit_prehook logic was broken out into its own
proc was so it could be invoked after the current set of files that
were already added to the commit could be refreshed if 'Allow Partially
Added Files' was set to false. Now that we no longer even offer that
option to the user there is no reason to keep this code broken out
into its own procedure.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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: 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: 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>
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>
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>
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>
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: 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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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').
$ 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.
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.
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>
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.
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.
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 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>
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>