kernel/git - git - PowerEL Git System

475 Commits

6 Branches

36 Tags

131 MiB

Tree: 774173aa5f

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	5b6ffff644	git-gui: GUI support for running 'git remote prune <name>' In some workflows it is common for a large number of temporary branches to be created in a remote repository, get fetched to clients that typically only use git-gui, and then later have those branches deleted from the remote repository once they have been fully merged into all destination branches. Users of git-gui would obviously like to have their local tracking branches cleaned up for them, otherwise their local tracking branch namespace would grow out of control. The best known way to remove these tracking branches is to run "git remote prune <remotename>". Even though it is more of a Porcelain command than plumbing I'm invoking it through the UI, because frankly I don't see a reason to reimplement its ls-remote output filtering and config file parsing. A new configuration option (gui.pruneduringfetch) can be used to automatically enable running "git remote prune <remotename>" after the fetch of that remote also completes successfully. This is off by default as it require an additional network connection and is not very fast on Cygwin if a large number of tracking branches have been removed (due to the 2 fork+exec calls per branch). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	a35d65d9c8	git-gui: Move console procs into their own namespace To help modularize git-gui better I'm isolating the code and variables required to handle our little console windows into their own namespace. This way we can say console::new rather than new_console, and the hidden internal procs to create the window and read data from our filehandle are off in their own private little land, where most users don't see them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	f522c9b5ed	git-gui: Refactor into multiple files to save my sanity I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago

Author

SHA1

Message

Date

Shawn O. Pearce

5b6ffff644

git-gui: GUI support for running 'git remote prune <name>'

In some workflows it is common for a large number of temporary
branches to be created in a remote repository, get fetched to
clients that typically only use git-gui, and then later have
those branches deleted from the remote repository once they have
been fully merged into all destination branches.  Users of git-gui
would obviously like to have their local tracking branches cleaned
up for them, otherwise their local tracking branch namespace would
grow out of control.

The best known way to remove these tracking branches is to run
"git remote prune <remotename>".  Even though it is more of a
Porcelain command than plumbing I'm invoking it through the UI,
because frankly I don't see a reason to reimplement its ls-remote
output filtering and config file parsing.

A new configuration option (gui.pruneduringfetch) can be used to
automatically enable running "git remote prune <remotename>" after
the fetch of that remote also completes successfully.  This is off
by default as it require an additional network connection and is
not very fast on Cygwin if a large number of tracking branches have
been removed (due to the 2 fork+exec calls per branch).

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

18 years ago

Shawn O. Pearce

a35d65d9c8

git-gui: Move console procs into their own namespace

To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace.  This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.

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

18 years ago

Shawn O. Pearce

f522c9b5ed

git-gui: Refactor into multiple files to save my sanity

I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.

This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI.  In many cases the user can avoid reading at least half
of git-gui now.

Unfortunately we now need a library directory in our runtime
location.  This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.

We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory.  I'm
hoping this is not an unncessary burden on end-users who are building
from source.

I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files.  All of
the new changes are to setup the library path and install the library
files.

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

18 years ago

3 Commits (774173aa5f24023a82ce79f2a71fe3f664b747ad)