* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-06 5:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708060054020.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
Johannes Schindelin said the following on 06.08.2007 02:11:
> On Mon, 6 Aug 2007, Torgil Svensson wrote:
>>>> 2. rxvt-terminal had some freezes
>>> I did not experience those. Could you research further?
>
> Those "freezes" were due to the fact that Rxvt incorrectly updates
> stderr in a blocking way, or not at all (don't know which). There
> are more things that do not work in Rxvt, and only after trying the
> same in cmd (which I do not like for various reasons) I found out
> that rxvt.exe is at fault.
>
> I would be glad if somebody managed to compile rxvt herself and fix
> all those bugs (see http://code.google.com/p/msysgit/ for a short
> list of the most pressing issues I found). As it is, I have enough
> work to do with the rest of msysGit, and for the moment, I can at
> least work in cmd. Even ssh push works.
Hi guys,
Instead of hacking away on this old terminal, what about simply
including another nice Open Source project?
On Windows we have a replacement terminal, which has all the features
you want, and also supports tabs like Konsole. I've used it for
several years, and it works great. Have a look and see if you like it,
then we can add it to the repo:
http://sourceforge.net/projects/console/
Original name, ey? :-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-06 5:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Ismail D?nmez, git
In-Reply-To: <7vr6mheem0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>>> So stop this *insane* insistence of emacs. You should learn to just
>>> assume that people don't even have it installed!
>>
>> We were discussing Texinfo, not Emacs. Please focus.
>
> I would welcome if the set of our documentation output formats
> included *.info pages.
>
> However, as the input format, texinfo _is_ painful. AsciiDoc is
> 100x easier.
If you are able to figure out what to write. Can you tell me how to
include one of the man pages in an appendix, with appropriate
substructure? I can't. It might be easy, but I find it impossible
to guess from the information just how.
> I've written documentaiton in texinfo format in the past, and one
> thing I found quite painful was maintaining the node header with
> prev/next links --- tedious, error prone and boring.
File: texinfo, Node: makeinfo Pointer Creation, Next: anchor, Prev: node, Up: Nodes
6.4 Creating Pointers with `makeinfo'
=====================================
The `makeinfo' program has a feature for automatically determining node
pointers for a hierarchically organized document.
When you take advantage of this feature, you do not need to write the
`Next', `Previous', and `Up' pointers after the name of a node.
However, you must write a sectioning command, such as `@chapter' or
`@section', on the line immediately following each truncated `@node'
line (except that comment lines may intervene).
In addition, you must follow the `Top' `@node' line with a line
beginning with `@top' to mark the `Top' node in the file. *Note
`@top': makeinfo top.
Finally, you must write the name of each node (except for the `Top'
node) in a menu that is one or more hierarchical levels above the
node's hierarchical level.
This implicit node pointer insertion feature in `makeinfo' relieves
you from the need to update menus and pointers manually or with Texinfo
mode commands. (*Note Updating Nodes and Menus::.)
> There is no good editor to help you maintain them other than Emacs
> texinfo mode as far as I know.
Then don't maintain them. It is not necessary.
Anyway, I suggest that people wanting to continue to berave me for
taking the word Texinfo into my mouth do this off-list. It is very
much clear that Texinfo is no-go as a source documentation format for
Git: it makes a considerable ratio of developers foam at the mouth.
And that simply rules it out.
It also turns out that makeinfo2x-texi is able to produce rather good
Texinfo from stuff written for book output with Asciidoc. Yes, there
are details missing, but it is nothing one could not slide in with
sed into the Texinfo file. And adding the absent indexing information
can be done in Asciidoc: that is documented.
In contrast, I have just tried using makeinfo --docbook on AUCTeX
Texinfo documentation, and the docbook XML it produces is not always
properly nested, and when one corrects that, the problems with
processing that just start: that seems not really tested, at least
with makeinfo 4.8.
So there is a good Docbook->info path, but not the other way round.
Anyway, you wrote:
> I would welcome if the set of our documentation output formats
> included *.info pages.
At least for the user manual, I can support this (without index) in a
dozen lines of makefile code and another dozen lines of sed (for
adding the top/dir entry information). Yes, this caught me quite by
surprise. For the indexing, of course one will have to insert the
appropriate Asciidoc markup into the source files. I can also work on
that, but it should likely be a colloborative effort: it leads to a
working Index also in the PDF output without the need to involve
Texinfo.
As for making the man pages part of the main manual: I don't know my
way around Asciidoc enough to be able to do this. It might be
possible to fudge around this issue with sed again, converting the
manual page sources to book section sources. I am sure there is a
more elegant way to do this sort of transformation/conversion either
on the Asciidoc or XML level, but it's beyond me.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-06 5:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708060119320.14781@racer.site>
On Aug 6, 2007, at 2:22 AM, Johannes Schindelin wrote:
> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
>> I found it quite useful to be able to commit diff chunks selectively.
>
> But how do you make sure that it works as expected? I.e. when you
> commit
> a hunk using, say, variable "rule_the_world", and by mistake
> (happen to me
> all the time, maybe to you, too?) forgot to select the hunk which
> declares
> that variable, maybe because it is hidden in a forest of other
> variables?
In various ways, the details depend on what I'm doing. Here are three
examples.
1) I push the commit to a faster machine to compile it there and
continue
working on the next commit (a complete build of the software package
that
I'm mostly working on takes approximately 30 min on our fastest
machines. I
can't wait for this before I continue working. Luckily a complete
compile is
rarely needed).
2) I don't care about a single commit. I only care about the result of a
series of commits. I need to check on multiple architectures anyway
and can't
thoroughly test what I'm doing right now. Regularly gcc and Microsoft
compilers disagree on warnings.
3) I push a series of commits to my scratch space and wait one night
for the
automated builds to complete on all architectures.
> I _try_ to test commits by my eyes, by compiling, and by running the
> version I'll commit. (Okay, sometimes I run the test _after_
> committing,
> but then I test to see if I have to amend something.)
Option (1) is probably the only solution that fulfills your
requirement that
every single commit should compile and work. This is a perfect
approach but
sometimes take too much time for me.
Steffen
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Steffen Prohaska @ 2007-08-06 4:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Theodore Tso, Johan Herland, git, Shawn O. Pearce, Miles Bader
In-Reply-To: <Pine.LNX.4.64.0708060116590.14781@racer.site>
On Aug 6, 2007, at 2:17 AM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
>>
>> On Aug 5, 2007, at 6:11 PM, Theodore Tso wrote:
>>
>>> On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
>>>> $ hg addremove --help
>>>> hg addremove [OPTION]... [FILE]...
>>>>
>>>> add all new files, delete all missing files
>>>>
>>>> Add all new files and remove all missing files from the
>>>> repository.
>>>>
>>>> New files are ignored if they match any of the patterns
>>>> in .hgignore.
>>>> As
>>>> with add, these changes take effect at the next commit.
>>>>
>>>> Adding a git-addremove command should not be much work, and it
>>>> would be a
>>>> lot friendlier to people whose workflow is more aligned with #2
>>>> than #1.
>>>
>>> Not much work at all:
>>>
>>> # git config --system --add alias.addremove "git add . ; git add -u"
>>
>> But how can I handle the [FILE]... from above?
>
> See
> http://git.or.cz/gitwiki/
> Aliases#head-714f0aa64cb53eda636d41e16bf2b99477588685
Thanks.
"Starting with version 1.5.3, git supports appending the
arguments to commands prefixed with "!", too. If you need
to perform a reordering, or to use an argument twice, you
can use this trick:
[alias]
example = !sh -c "ls $1 $0"
NOTE: the arguments start with $0, not with $1 as you are
used from shell scripts." [cited from the link above]
should do the job.
Steffen
^ permalink raw reply
* [PATCH 5/5] documentation: use the word "index" in the git-commit man page
From: J. Bruce Fields @ 2007-08-06 4:34 UTC (permalink / raw)
To: gitster; +Cc: git, J. Bruce Fields, J. Bruce Fields
In-Reply-To: <0eb4f7cdf85273c88feb95c677a808cee9cfd859.1186373089.git.bfields@pig.linuxdev.us.dell.com>
From: J. Bruce Fields <bfields@pig.linuxdev.us.dell.com>
As with git-add, I think previous updates to the git-commit man page did
indeed help make it more user-friendly. But I think the banishment of
the word "index" from the description goes too far; reinstate its use,
to simplify some of the language slightly and smooth the transition to
other documentation.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-commit.txt | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..f07a330 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -15,26 +15,26 @@ SYNOPSIS
DESCRIPTION
-----------
-Use 'git commit' when you want to record your changes into the repository
-along with a log message describing what the commit is about. All changes
-to be committed must be explicitly identified using one of the following
-methods:
+Use 'git commit' to store the current contents of the index in a new
+commit along with a log message describing the changes you have made.
+The content to be added can be specified in several ways:
1. by using gitlink:git-add[1] to incrementally "add" changes to the
- next commit before using the 'commit' command (Note: even modified
+ index before using the 'commit' command (Note: even modified
files must be "added");
-2. by using gitlink:git-rm[1] to identify content removal for the next
- commit, again before using the 'commit' command;
+2. by using gitlink:git-rm[1] to remove files from the working tree
+ and the index, again before using the 'commit' command;
-3. by directly listing files containing changes to be committed as arguments
- to the 'commit' command, in which cases only those files alone will be
- considered for the commit;
+3. by listing files as arguments to the 'commit' command, in which
+ case the commit will ignore changes staged in the index, and instead
+ record the current content of the listed files;
-4. by using the -a switch with the 'commit' command to automatically "add"
- changes from all known files i.e. files that have already been committed
- before, and to automatically "rm" files that have been
- removed from the working tree, and perform the actual commit.
+4. by using the -a switch with the 'commit' command to automatically
+ "add" changes from all known files (i.e. all files that are already
+ listed in the index) and to automatically "rm" files in the index
+ that have been removed from the working tree, and then perform the
+ actual commit;
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
--
1.5.3.GIT
^ permalink raw reply related
* [PATCH 4/5] documentation: use the word "index" in the git-add manual page
From: J. Bruce Fields @ 2007-08-06 4:34 UTC (permalink / raw)
To: gitster; +Cc: git, J. Bruce Fields, J. Bruce Fields
In-Reply-To: <0eb4f7cdf85273c88feb95c677a808cee9cfd859.1186373089.git.bfields@pig.linuxdev.us.dell.com>
From: J. Bruce Fields <bfields@pig.linuxdev.us.dell.com>
It was a neat trick to show that you could introduce the git-add manual
page without using the word "index", and it was certainly an improvement
over the previous man page (which started out "A simple wrapper for
git-update-index to add files to the index...").
But it's possible to use the standard terminology without sacrificing
user-friendliness. So, rewrite to use the word "index" when
appropriate.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-add.txt | 41 ++++++++++++++++++++++-------------------
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index a0c9f68..37077b5 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -3,7 +3,7 @@ git-add(1)
NAME
----
-git-add - Add file contents to the changeset to be committed next
+git-add - Add file contents to the index
SYNOPSIS
--------
@@ -11,24 +11,27 @@ SYNOPSIS
DESCRIPTION
-----------
-All the changed file contents to be committed together in a single set
-of changes must be "added" with the 'add' command before using the
-'commit' command. This is not only for adding new files. Even modified
-files must be added to the set of changes about to be committed.
-
-This command can be performed multiple times before a commit. The added
-content corresponds to the state of specified file(s) at the time the
-'add' command is used. This means the 'commit' command will not consider
-subsequent changes to already added content if it is not added again before
-the commit.
-
-The 'git status' command can be used to obtain a summary of what is included
-for the next commit.
-
-This command can be used to add ignored files with `-f` (force)
-option, but they have to be
-explicitly and exactly specified from the command line. File globbing
-and recursive behaviour do not add ignored files.
+This command adds the current content of new or modified files to the
+index, thus staging that content for inclusion in the next commit.
+
+The "index" holds a snapshot of the content of the working tree, and it
+is this snapshot that is taken as the contents of the next commit. Thus
+after making any changes to the working directory, and before running
+the commit command, you must use the 'add' command to add any new or
+modified files to the index.
+
+This command can be performed multiple times before a commit. It only
+adds the content of the specified file(s) at the time the add command is
+run; if you want subsequent changes included in the next commit, then
+you must run 'git add' again to add the new content to the index.
+
+The 'git status' command can be used to obtain a summary of which
+files have changes that are staged for the next commit.
+
+The 'add' command can be used to add ignored files with `-f` (force)
+option, but they have to be explicitly and exactly specified from the
+command line. File globbing and recursive behaviour do not add ignored
+files.
Please see gitlink:git-commit[1] for alternative ways to add content to a
commit.
--
1.5.3.GIT
^ permalink raw reply related
* [PATCH 1/5] user-manual: update for new default --track behavior
From: J. Bruce Fields @ 2007-08-06 4:33 UTC (permalink / raw)
To: gitster; +Cc: git, J. Bruce Fields, J. Bruce Fields
In-Reply-To: <11863748422001-git-send-email->
From: J. Bruce Fields <bfields@pig.linuxdev.us.dell.com>
Update documentation to reflect the --track default.
That change seems to have happened in the 1.5.3 -rc's, so bump the "for
version x.y.z or newer" warning as well.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0071cd0..c0820e9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1,4 +1,4 @@
-Git User's Manual (for version 1.5.1 or newer)
+Git User's Manual (for version 1.5.3 or newer)
______________________________________________
@@ -1667,24 +1667,19 @@ one step:
$ git pull origin master
-------------------------------------------------
-In fact, "origin" is normally the default repository to pull from,
-and the default branch is normally the HEAD of the remote repository,
-so often you can accomplish the above with just
+In fact, if you have "master" checked out, then by default "git pull"
+merges from the HEAD branch of the origin repository. So often you can
+accomplish the above with just a simple
-------------------------------------------------
$ git pull
-------------------------------------------------
-See the descriptions of the branch.<name>.remote and branch.<name>.merge
-options in gitlink:git-config[1] to learn how to control these defaults
-depending on the current branch. Also note that the --track option to
-gitlink:git-branch[1] and gitlink:git-checkout[1] can be used to
-automatically set the default remote branch to pull from at the time
-that a branch is created:
-
--------------------------------------------------
-$ git checkout --track -b maint origin/maint
--------------------------------------------------
+More generally, a branch that is created from a remote branch will pull
+by default from that branch. See the descriptions of the
+branch.<name>.remote and branch.<name>.merge options in
+gitlink:git-config[1], and the discussion of the --track option in
+gitlink:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
producing a default commit message documenting the branch and
--
1.5.3.GIT
^ permalink raw reply related
* [PATCH 3/5] user-manual: mention git-gui
From: J. Bruce Fields @ 2007-08-06 4:34 UTC (permalink / raw)
To: gitster; +Cc: git, J. Bruce Fields, J. Bruce Fields
In-Reply-To: <0eb4f7cdf85273c88feb95c677a808cee9cfd859.1186373089.git.bfields@pig.linuxdev.us.dell.com>
From: J. Bruce Fields <bfields@pig.linuxdev.us.dell.com>
The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.
One feature of interest is the ability to manipulate individual diff
hunks. However, people have found that feature not to be easily
discoverable from the user-interface. Pending some ui improvements, a
parenthetical hint here may help.
(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 9efe85c..f89952a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1079,6 +1079,11 @@ $ git diff HEAD # difference between HEAD and working tree; what
$ git status # a brief per-file summary of the above.
-------------------------------------------------
+You can also use gitlink:git-gui[1] to create commits, view changes in
+the index and the working tree files, and individually select diff hunks
+for inclusion in the index (by right-clicking on the diff hunk and
+choosing "Stage Hunk For Commit").
+
[[creating-good-commit-messages]]
Creating good commit messages
-----------------------------
@@ -2506,8 +2511,10 @@ $ gitk origin..mywork &
And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit
---amend.
+cherry-pick, and possibly modifying them as you go using commit --amend.
+The git-gui[1] command may also help as it allows you to individually
+select diff hunks for inclusion in the index (by right-clicking on the
+diff hunk and choosing "Stage Hunk for Commit").
Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:
--
1.5.3.GIT
^ permalink raw reply related
* [PATCH 2/5] user-manual: mention git stash
From: J. Bruce Fields @ 2007-08-06 4:33 UTC (permalink / raw)
To: gitster; +Cc: git, Junio C Hamano, J. Bruce Fields
In-Reply-To: <0eb4f7cdf85273c88feb95c677a808cee9cfd859.1186373089.git.bfields@pig.linuxdev.us.dell.com>
From: Junio C Hamano <gitster@pobox.com>
Mention the git-stash command as a way to temporarily set aside work in
progress.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c0820e9..9efe85c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1484,6 +1484,38 @@ $ git show HEAD^:path/to/file
which will display the given version of the file.
+[[interrupted-work]]
+Temporarily setting aside work in progress
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+While you are in the middle of working on something complicated, you
+find an unrelated but obvious and trivial bug. You would like to fix it
+before continuing. You can use gitlink:git-stash[1] to save the current
+state of your work, and after fixing the bug (or, optionally after doing
+so on a different branch and then coming back), unstash the
+work-in-progress changes.
+
+------------------------------------------------
+$ git stash "work in progress for foo feature"
+------------------------------------------------
+
+This command will save your changes away to the `stash`, and
+reset your working tree and the index to match the tip of your
+current branch. Then you can make your fix as usual.
+
+------------------------------------------------
+... edit and test ...
+$ git commit -a -m "blorpl: typofix"
+------------------------------------------------
+
+After that, you can go back to what you were working on with
+`git stash apply`:
+
+------------------------------------------------
+$ git stash apply
+------------------------------------------------
+
+
[[ensuring-good-performance]]
Ensuring good performance
-------------------------
--
1.5.3.GIT
^ permalink raw reply related
* Documentation patches
From: J. Bruce Fields @ 2007-08-06 4:33 UTC (permalink / raw)
To: gitster; +Cc: git
> (Oh, and my own attempt, along with a couple other minor manual updates,
> is in the master branch at
>
> git://linux-nfs.org/~bfields/git.git master
>
> Feel free to take that whenever, if it looks OK, Junio.)
Here you are--a small --track update, stash and gui mentions, then a
couple patches to bring the word "index" back to a couple man pages.
--b.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-08-06 4:06 UTC (permalink / raw)
To: Brett Schwarz; +Cc: J. Bruce Fields, Steffen Prohaska, git
In-Reply-To: <608102.66070.qm@web38905.mail.mud.yahoo.com>
Brett Schwarz <brett_schwarz@yahoo.com> wrote:
> > From: Shawn O. Pearce <spearce@spearce.org>
> >
> > I haven't explored any in-Tk rendering options yet, been too busy
> > with other projects. Ideally I'd like to just render the asciidoc
> > markup directly, but I don't think anyone has done an asciidoc
> > viewer for Tk. I can't imagine it would be that difficult to get
> > some sort of parser working though...
> >
> >
>
> So, I took a stab at this earlier today, and it is fairly straight forward. I have
> something that is semi working (I haven't tested all the scenarios yet), but
> the rest is just really filling in the blanks.
Yea, I thought it would be really straight-forward. The Tk text
widget is a really wonderful tool. Makes these sorts things almost
write themselves...
> Question though: I was going to have a index tree on a side panel...but do
> you want this thing to only bring up the git-gui.txt file, and show the table
> of contents, or do you want all *.txt files in the index? Or .... ?
Yea, that's a good question. I think I want all of that. ;-)
I mean:
I'd like to be able to allow users to browse all of the Git manual
pages and the user manual, directly from within git-gui. Then I
can setup a new subcommand `git gui help commit` to bring up the
git-commit manual page in this renderer (for example). So in that
sense showing all of the manuals in an index is really useful.
This may make it easier for some users (e.g me!) as they don't have
to render the manuals, or rely upon the man/html branches from Junio.
I'd like to let users also browse the git user manual. This is
a fairly large set of documentation, so the table of contents for
this thing is not just a list; a proper tree that one can browse
through is really nice.
And I'd like to start writing git-gui specific documentation,
and let users browse through that as well.
So whatever you can provide is great. And you don't have to get
everything at once either; just showing single files would be a
great start. Showing single files with the various section headers
in an "outline" view to the left would be even better.
I think one of the worst manuals we have is git-fast-import.
Its huge. It uses a number of asciidoc features, and it has
a fairly large outline. The user manual is actually a lot
more complex, but isn't a single file manual page. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-06 3:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, gitster, git
In-Reply-To: <Pine.LNX.4.64.0708060124120.14781@racer.site>
On Mon, Aug 06, 2007 at 01:26:21AM +0100, Johannes Schindelin wrote:
> On Sun, 5 Aug 2007, J. Bruce Fields wrote:
> > A big warning would be out of place in what is for now just an isolated
> > sentence in two different places. But I agree with you that this would
> > be worth mentioning in any eventual full-fledged git-gui tutorial.
>
> Unfortunately, I am really wasted by this weekend's efforts to bring
> msysgit.git along... could you be so kind as to cut&paste the relevant
> section in a reply to me, so I do not have to search for myself?
Sure; appended. This isn't that different from Steffen's proposal.
> I would not normally ask for such a favour; it is relatively easy to go on
> a search with Git, but I do have only 8 hours of sleep in the last 60
> hours under my saddle...
Hm. On the other hand, maybe we should just be refusing to feed your
addiction till you get some sleep.
I wanna keep this short for now, so if we really think we shouldn't
mention of the hunk-selection thing without a warning, I'd rather just
omit mention of it, and go for something like: "You can also use
gitlink:git-gui[1] to create commits and view changes in the index and
working tree", and drop the second hunk. Whatever.
--b.
>From 407c0c87e15b3cf60347f4fc0bcdb4d239de4163 Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@pig.linuxdev.us.dell.com>
Date: Sun, 5 Aug 2007 18:12:37 -0400
Subject: [PATCH] user-manual: mention git-gui
The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.
One feature of interest is the ability to manipulate individual diff
hunks. However, people have found that feature not to be easily
discoverable from the user-interface. Pending some ui improvements, a
parenthetical hint here may help.
(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 9efe85c..f89952a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1079,6 +1079,11 @@ $ git diff HEAD # difference between HEAD and working tree; what
$ git status # a brief per-file summary of the above.
-------------------------------------------------
+You can also use gitlink:git-gui[1] to create commits, view changes in
+the index and the working tree files, and individually select diff hunks
+for inclusion in the index (by right-clicking on the diff hunk and
+choosing "Stage Hunk For Commit").
+
[[creating-good-commit-messages]]
Creating good commit messages
-----------------------------
@@ -2506,8 +2511,10 @@ $ gitk origin..mywork &
And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit
---amend.
+cherry-pick, and possibly modifying them as you go using commit --amend.
+The git-gui[1] command may also help as it allows you to individually
+select diff hunks for inclusion in the index (by right-clicking on the
+diff hunk and choosing "Stage Hunk for Commit").
Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:
--
1.5.3.GIT
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-06 3:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708060419230.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > I recommend against that, too. All too often, I have some temporary files
>> > in the working tree, and I'll be dimmed if I'm the only one. So
>> > "addremove" adds too much possibility for pilot errors.
>>
>> "Recommend against it"? Why?
>
> Didn't I say that? It just _asks_ for pilot errors.
Huh? How is it any worse than the underlying commands it uses
("git add ." in particular)?! Indeed, it seems rather less likely to
cause problems, because it has a rather odd name.
>> It's a separate command, so if it doesn't fit your working style, don't
>> use it.
>
> Hah! If that were true, we'd have a lot less mails like "I tried this and
> it did not work", only to find out that the person assumed that
> documentation is for wimps, and tried a command that "sounded" like it
> would do the right thing.
Git is not exactly a user-coddling, ultra-hand-holding application, nor
does it seem to have that as a goal. It offers _tons_ of rope to hang
yourself if you wish (though it usually offers lots of ways to recover).
Rather git seems to have as a goal being a useful toolkit for managing
source trees, and based on what I've seen, tries to accomodate many
different styles of usage (rather than trying to force a certain style
down the users' throats -- as some VCSs try to do ...).
-miles
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Brett Schwarz @ 2007-08-06 3:33 UTC (permalink / raw)
To: Shawn O. Pearce, J. Bruce Fields; +Cc: Steffen Prohaska, git
>
> ----- Original Message ----
> From: Shawn O. Pearce <spearce@spearce.org>
> To: J. Bruce Fields <bfields@fieldses.org>
> Cc: Steffen Prohaska <prohaska@zib.de>; git@vger.kernel.org
> Sent: Friday, August 3, 2007 11:20:10 PM
> Subject: Re: [PATCH] user-manual: mention git gui citool (commit, amend)
>
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > On Thu, Aug 02, 2007 at 11:04:59PM -0400, Shawn O. Pearce wrote:
> > > Online help? In git-gui? :-)
> > >
> > > We don't have an online help system yet.
> >
> > Fair enough.
> >
> > Though I'd like to keep the main body of the manual focused on the major
> > command line tools, I'd have no objection to a separate chapter (or
> > appendix?) devoted to git-gui; then you could point directly at that.
> > Would that make sense?
>
> Yea, that makes a lot of sense. git-gui isn't a full replacement
> for the command line anyway, so I would never suggest a wholesale
> rewrite of the user manual to slant the entire thing towards git-gui.
> Doing so would only point out the many shortcomings in git-gui. :)
>
> I haven't explored any in-Tk rendering options yet, been too busy
> with other projects. Ideally I'd like to just render the asciidoc
> markup directly, but I don't think anyone has done an asciidoc
> viewer for Tk. I can't imagine it would be that difficult to get
> some sort of parser working though...
>
>
So, I took a stab at this earlier today, and it is fairly straight forward. I have
something that is semi working (I haven't tested all the scenarios yet), but
the rest is just really filling in the blanks.
Question though: I was going to have a index tree on a side panel...but do
you want this thing to only bring up the git-gui.txt file, and show the table
of contents, or do you want all *.txt files in the index? Or .... ?
Thanks,
--brett
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-06 3:21 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buo1wehxssa.fsf@dhapc248.dev.necel.com>
Hi,
[please, netiquette says that you should Cc _at least_ the one you're
responding to]
On Mon, 6 Aug 2007, Miles Bader wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> But I'm wondering whether we'd want to include it in git by default
> >> (instead of having to tell confused users to add the alias).
> >
> > I recommend against that, too. All too often, I have some temporary files
> > in the working tree, and I'll be dimmed if I'm the only one. So
> > "addremove" adds too much possibility for pilot errors.
>
> "Recommend against it"? Why?
Didn't I say that? It just _asks_ for pilot errors.
> It's a separate command, so if it doesn't fit your working style, don't
> use it.
Hah! If that were true, we'd have a lot less mails like "I tried this and
it did not work", only to find out that the person assumed that
documentation is for wimps, and tried a command that "sounded" like it
would do the right thing.
Ciao,
Dscho
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-06 3:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708060112330.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> But I'm wondering whether we'd want to include it in git by default
>> (instead of having to tell confused users to add the alias).
>
> I recommend against that, too. All too often, I have some temporary files
> in the working tree, and I'll be dimmed if I'm the only one. So
> "addremove" adds too much possibility for pilot errors.
"Recommend against it"? Why?
It's a separate command, so if it doesn't fit your working style, don't
use it. I think it _is_ a well-defined and useful action ("snapshot the
working dir") that people would sometimes like to perform, and having a
simple git command to do it would be good.
Morever, as an almost trivial alias, "code bloat" is hardly an argument
against it!
[But please, call it "addrm" -- "addremove" is just gratuitously long...]
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
^ permalink raw reply
* Re: gitbox status (for those who want to hack on it)
From: Johannes Schindelin @ 2007-08-06 2:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0708051841w4701d04dw894b61c5a26d6ed5@mail.gmail.com>
Hi,
On Sun, 5 Aug 2007, Nguyen Thai Ngoc Duy wrote:
> On 8/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Sat, 4 Aug 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > I would say it's in pretty good state now because it can run through
> > > test cases. Running tests on Windows can take about an hour so I'll
> > > put test results here so you don't have to rerun the whole thing if
> > > you want to know what part needs work.
> >
> > I think your project is awesome. Unfortunately, I did not have time to
> > check it out yet -- work-tree regressions and msysgit keep me occupied,
> > along with daytime job...
>
> Hey no worries. msysgit is actually good job.
Gee thanks!
> BTW, where was msysgit.git going? I recall I saw something there in
> repo.or.cz, now it's gone.
No, it's still there: http://repo.or.cz/w/msysgit.git
What you probably saw (for a while) was my unsuccessful attempt to make
this a fork of mingw.git, which is a fork of git.git.
Ciao,
Dscho
^ permalink raw reply
* Re: gitbox status (for those who want to hack on it)
From: Nguyen Thai Ngoc Duy @ 2007-08-06 1:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708051635170.14781@racer.site>
On 8/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 4 Aug 2007, Nguyen Thai Ngoc Duy wrote:
>
> > I would say it's in pretty good state now because it can run through
> > test cases. Running tests on Windows can take about an hour so I'll
> > put test results here so you don't have to rerun the whole thing if
> > you want to know what part needs work.
>
> I think your project is awesome. Unfortunately, I did not have time to
> check it out yet -- work-tree regressions and msysgit keep me occupied,
> along with daytime job...
Hey no worries. msysgit is actually good job. BTW, where was
msysgit.git going? I recall I saw something there in repo.or.cz, now
it's gone.
--
Duy
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-06 1:17 UTC (permalink / raw)
To: git
In-Reply-To: <f9459f$ik$1@sea.gmane.org>
[Cc: Asger Ottar Alstrup <asger@ottaralstrup.dk>, git@vger.kernel.org]
Asger Ottar Alstrup wrote:
> Jakub Narebski wrote:
>> Open forum
>>
>> 1. What other comments or suggestions do you have that are not
>> covered by the questions above?
>
> I believe there is a need for hosting services of Git repositories for
> commercial use.
>
> With the Windows Git installer coming along, I know that I'd like to
> switch our company from a SVN hosted at cvsdude.com or svnrepository.com
> to a Git hosting service.
>
> Maybe you could include a question about this?
I don't quite understand: what would be the question? Note that survey is
meant to help git community notice what needs improvements.
Besides, you can always put above _answer_ ("I believe...") in this
open-forum question...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Jakub Narebski @ 2007-08-06 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <200708051411.25238.johan@herland.net>
Johan Herland wrote:
> So different users seem to have two different (almost incompatible)
> expectations to git-add:
>
> 1. git-add adds new files into the index. git-add has _no_ business removing
> deleted files from the index.
>
> 2. git-add updates the index according to the state of the working tree.
> This includes adding new files and removing deleted files.
>
>
> Both interpretations are useful and worth supporting, but git-add currently
> seems focused on #1 (and rightly so, IMHO).
>
> Even though #2 can be achieved by using a couple of git-add commmands (or a
> longer series of more obscure plumbing-level commands), it might be worth
> considering the more user-friendly alternative of adding a dedicated
> command for supporting #2. Such a command already exists in a similar RCS:
>
> ---
> $ hg addremove --help
> hg addremove [OPTION]... [FILE]...
>
> add all new files, delete all missing files
git update-index --add --remove?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Johannes Schindelin @ 2007-08-06 0:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708052206.31734.jnareb@gmail.com>
Hi,
On Sun, 5 Aug 2007, Jakub Narebski wrote:
> On Sat, 4 August 2007, David Kastrup wrote:
> >
> > I miss a question about developer and mailing list attitude. That is
> > often inversely proportional to the quality of help and support: one
> > has forums where lots of friendly people without much of a clue hang
> > out, and then there are some where one can always get competent and
> > fast help in one package with an ulcer.
>
> What about a compromise (question)?
>
> ----
> Getting help, staying in touch
>
> [...]
>
> 10. Did you have problems getting GIT help on mailing list or
> on IRC channel? What were those problems? What could be improved?
Much better.
Because otherwise, you'd have to have another question:
10a: Did you ever experience somebody on the mailing list who
perfectly fits the profile described here:
http://developers.slashdot.org/article.pl?sid=07/03/12/1449201
And admittedly, this has _nothing at all_ to do with Git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Johannes Schindelin @ 2007-08-06 0:26 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Steffen Prohaska, gitster, git
In-Reply-To: <20070805222213.GA12168@fieldses.org>
Hi,
On Sun, 5 Aug 2007, J. Bruce Fields wrote:
> On Sun, Aug 05, 2007 at 02:58:11PM +0100, Johannes Schindelin wrote:
> > On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> >
> > > git gui is especially useful because it allows to select diff hunks.
> >
> > You should give a _big_ _fat_ _red_ warning there.
> >
> > If you selectively commit diff hunks, you _never_ tested what you
> > committed.
>
> A big warning would be out of place in what is for now just an isolated
> sentence in two different places. But I agree with you that this would
> be worth mentioning in any eventual full-fledged git-gui tutorial.
Unfortunately, I am really wasted by this weekend's efforts to bring
msysgit.git along... could you be so kind as to cut&paste the relevant
section in a reply to me, so I do not have to search for myself?
I would not normally ask for such a favour; it is relatively easy to go on
a search with Git, but I do have only 8 hours of sleep in the last 60
hours under my saddle...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Johannes Schindelin @ 2007-08-06 0:22 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <5AB64D44-2324-4A98-B010-8D6D6225F116@zib.de>
Him
On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> I found it quite useful to be able to commit diff chunks selectively.
But how do you make sure that it works as expected? I.e. when you commit
a hunk using, say, variable "rule_the_world", and by mistake (happen to me
all the time, maybe to you, too?) forgot to select the hunk which declares
that variable, maybe because it is hidden in a forest of other variables?
I _try_ to test commits by my eyes, by compiling, and by running the
version I'll commit. (Okay, sometimes I run the test _after_ committing,
but then I test to see if I have to amend something.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] send-email: let sanitize_address_rfc822 do rfc2047 quoting
From: Jakub Narebski @ 2007-08-06 0:21 UTC (permalink / raw)
To: git
In-Reply-To: <11863445481996-git-send-email-ukleinek@informatik.uni-freiburg.de>
[Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>,
git@vger.kernel.org]
Uwe Kleine-König wrote:
> Without this patch I'm not able to properly send emails as I have a
> non-ascii character in my name.
Nice.
> The former version tried to fix-up the real name part with double quotes
> if it includes a '.'. I removed this as rfc2047 can handle a dot, too.
Not nice. I'd rather use double quotes if rfc2047 is not needed.
It means:
- no quotes for us-ascii name, without '.'
- quotes for us-ascii name with '.' and perhaps other forbidden characters
like '"' or something
- full rfc2047 quoting if name contains characters outside us-ascii.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-06 0:17 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Theodore Tso, Johan Herland, git, Shawn O. Pearce, Miles Bader
In-Reply-To: <C3725674-7B33-4B2F-9386-704540D51C0E@zib.de>
Hi,
On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
> On Aug 5, 2007, at 6:11 PM, Theodore Tso wrote:
>
> > On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
> > > $ hg addremove --help
> > > hg addremove [OPTION]... [FILE]...
> > >
> > > add all new files, delete all missing files
> > >
> > > Add all new files and remove all missing files from the repository.
> > >
> > > New files are ignored if they match any of the patterns in .hgignore.
> > > As
> > > with add, these changes take effect at the next commit.
> > >
> > > Adding a git-addremove command should not be much work, and it would be a
> > > lot friendlier to people whose workflow is more aligned with #2 than #1.
> >
> > Not much work at all:
> >
> > # git config --system --add alias.addremove "git add . ; git add -u"
>
> But how can I handle the [FILE]... from above?
See
http://git.or.cz/gitwiki/Aliases#head-714f0aa64cb53eda636d41e16bf2b99477588685
Hth,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox