* How to figure out what 'git push' would do?
From: Steffen Prohaska @ 2007-08-05 11:37 UTC (permalink / raw)
To: Git Mailing List
How can I check what a 'git push' would do, without
actually doing it?
Is there something like 'git push --dry-run', similar
to 'rsync --dry-run'?
Steffen
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 11:38 UTC (permalink / raw)
To: git
In-Reply-To: <20070805110200.GA18083@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Aug 05, 2007 at 12:56:49PM +0200, Steffen Prohaska wrote:
>
>> beyond my imagination that I could have a local following/automerging
>> branch that is directly referring to a branch in a remote repo, without
>> have a remote-tracking branch.
>>
>> How could I create such a setup in the first place?
>>
>> git branch --track something origin/something
>> git checkout --track -b something origin/something
>>
>> are obvious, but what to say if I don't have origin/something?
>
> I believe the --track setup uses the tracking branches to figure out
> which remote/branch combo to track. To do it without a remote tracking
> branch, you would have to add the lines to your .git/config manually.
Fascinating, really fascinating. Is there actually _anybody_ who
would not revert to phrases like "I believe" when describing git's
interaction with remote branches?
I don't find this particularly logical: origin/something basically
boils down referring to a commit.
Maybe git-branch --track should allow referring to remote:branch or
URLs or something directly rather than a remote tracking branch?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: How to figure out what 'git push' would do?
From: David Kastrup @ 2007-08-05 11:42 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <267CDD46-549B-4BFE-B993-80CD1CFE75D8@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> How can I check what a 'git push' would do, without
> actually doing it?
>
> Is there something like 'git push --dry-run', similar
> to 'rsync --dry-run'?
Wel, you could put
#!/bin/sh
cat >/tmp/dryrun
exit 1
into
$GIT_DIR/hooks/pre-receive
on the receiving side. Or maybe the update hook.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 11:52 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85tzre8b4w.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 01:38:07PM +0200, David Kastrup wrote:
> > I believe the --track setup uses the tracking branches to figure out
> > which remote/branch combo to track. To do it without a remote tracking
> > branch, you would have to add the lines to your .git/config manually.
>
> Fascinating, really fascinating. Is there actually _anybody_ who
> would not revert to phrases like "I believe" when describing git's
> interaction with remote branches?
By "I believe", I meant "I am pretty sure this is the way it is
implemented, but I have better things to do than read through
builtin-branch.c right now, so please don't take this as gospel and go
read the code yourself."
But the point of --track is that I don't _have_ to care, and that it
deduces the correct remote/branch combination itself.
> I don't find this particularly logical: origin/something basically
> boils down referring to a commit.
Really, "origin/something" refers to "refs/remotes/origin/something",
which we can deduce from the config to be populated by a particular
remote and branch (go read the code).
> Maybe git-branch --track should allow referring to remote:branch or
> URLs or something directly rather than a remote tracking branch?
It could, but at that point, you could just do:
git-branch newbranch oldbranch
git-config branch.newbranch.remote someremote
git-config branch.newbranch.merge remotebranch
Perhaps it's slightly more convenient to be able to do
git-branch --track someremote:remotebranch newbranch oldbranch
but the real convenience of --track is when it deduces those parameters
itself.
-Peff
^ permalink raw reply
* Re: $GIT_DIR usage
From: Dmitry Kakurin @ 2007-08-05 11:55 UTC (permalink / raw)
To: Dan Zwell; +Cc: git
In-Reply-To: <46B59F63.8020707@gmail.com>
I think you also need to set GIT_WORK_TREE.
This way Git will know the root of directories that it controls.
- Dmitry
----- Original Message -----
From: "Dan Zwell" <dzwell@gmail.com>
Newsgroups: gmane.comp.version-control.git
To: <git@vger.kernel.org>
Sent: Sunday, 5 August 2007 2:58
Subject: $GIT_DIR usage
> Hi, I had a question about $GIT_DIR. That is to say, it doesn't seem to
> work. I am using Git 1.5.2.4. See the following: (all the commands I
> tried besides "git-init" failed).
>
> $ export GIT_DIR="`pwd`/.git_public"
> $ git init
> warning: templates not found /usr/share//git-core/templates/
> Initialized empty Git repository in /home/user/temp/.git_public/
> $ echo > new_file
> $ git add new_file
> fatal: add must be run in a work tree
> $ git commit -a
> fatal: /usr/bin/git-commit cannot be used without a working tree.
> $ git commit
> fatal: /usr/bin/git-commit cannot be used without a working tree.
> $
>
> Is $GIT_DIR not meant to be used this way? Does it have a different
> purpose / use case, or is this just a bug?
>
> Thanks,
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-05 12:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, J. Bruce Fields
In-Reply-To: <20070803125601.GA28323@fieldses.org>
On Aug 3, 2007, at 2:56 PM, J. Bruce Fields wrote:
> On Thu, Aug 02, 2007 at 11:01:01PM -0400, Shawn O. Pearce wrote:
>> Steffen, you seem to be more in-tune with the Mac UI standards
>> than I am. Any suggestions on what I can do in git-gui to make
>> this feature more obvious to users?
From time to time I have a look at the Apple Human Interface
Guidelines [1]. They contain large Apple specific sections but also
ideas of general interest.
>> I myself use a Mac OS X based PowerBook as my primary development
>> system, but I have to admit, I'm not the best GUI developer that has
>> ever walked on this planet. Far far far from it.
>
> You're way ahead of me!
>
>> So I'd really love to do better. But frankly I'm at a loss here
>> and just don't know what sort of change to make.
>
>> Side note: Someone recently asked me how to move individual files
>> to the left side of the UI (to stage them). Apparently this person
>> had been using git-gui for months by just clicking "Add Existing"
>> (recently renamed to "Stage Changed"). It never occurred to the
>> user to try clicking the file's individual icons. Or to select
>> the files they were interested in and look for a menu option that
>> might work on that selection.
>
> The one thing that struck me when I fired up git-gui was that it
> wasn't
> obvious to me which things I should try clicking on.
I had the same experience. I didn't recognize that the document
icon left to a filename is actually a button with an action
attached to it. I thought it would be there just to distinguish
a file from a directory.
I'd tend to use kind of a push button instead of an icon to
indicate the action of adding a file to the index (staging).
Maybe an arrow facing left? And an arrow facing right to
unstage?
> For example: the buttons, drop-down menus, and check-boxes all cry out
> to be played with. But the filenames in the lists at the top are less
> obvious, and it might never have occurred to me on my own to right-
> click
> on the diff hunks at the bottom. That just looks like passive
> colorized
> text to me.
>
> I don't know what sort of user-interface conventions say "play with
> me!", though. Random ideas:
>
> - maybe the cursor should change shape over the diff hunks (or
> just the headers?)
> - maybe buttons, hunk headers, file names, etc., should all be
> in the same color?
> - maybe the hunk headers could benefit from a little more
> decoration? I don't know how to do that without just making
> the display look more cluttered, though.
> - maybe left-clicking on diff hunks should do something too?
In general it's always a good idea to make every action
accessible with only a single (left) mouse button. This
may seem ridiculous nowadays, but it really help to keep
things obvious. Right buttons and context menus have a
value for the experienced user to access things more
efficiently, but they should not be essential.
Steffen
[1] http://developer.apple.com/documentation/UserExperience/
Conceptual/OSXHIGuidelines/index.html
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johan Herland @ 2007-08-05 12:11 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Miles Bader
In-Reply-To: <20070805041320.GH9527@spearce.org>
On Sunday 05 August 2007, Shawn O. Pearce wrote:
> Miles Bader <miles@gnu.org> wrote:
> > I previously wrote
> > > One thing I often want to do is git-add all untracked files, and also
> > > automatically git-rm all "disappeared" files
> > ...
> > > One way to do this seems to be just "git add ."
> >
> > Oh, also, "git add ." doesn't seem to do the right thing with
> > "dissapeared" files: If I do:
> >
> > mv foo.cc bar.cc
> > git add .
>
> Right. Who wants "add" to actually mean "add and delete"?
> Shouldn't that be then called "git-add-and-rm"?
>
> We recently talked about this on the mailing list and decided that
> git-add shouldn't remove files that have disappeared, as doing so
> might break most user's expections of what git-add does.
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
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.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 12:12 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070805115208.GA19734@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Aug 05, 2007 at 01:38:07PM +0200, David Kastrup wrote:
>
>> > I believe the --track setup uses the tracking branches to figure out
>> > which remote/branch combo to track. To do it without a remote tracking
>> > branch, you would have to add the lines to your .git/config manually.
>>
>> Fascinating, really fascinating. Is there actually _anybody_ who
>> would not revert to phrases like "I believe" when describing git's
>> interaction with remote branches?
>
> By "I believe", I meant "I am pretty sure this is the way it is
> implemented, but I have better things to do than read through
> builtin-branch.c right now, so please don't take this as gospel and go
> read the code yourself."
Well, that is pretty much exactly what I find fascinating: that the
behavior is arbitrary and undocumented enough that one can't deduce it
either by logic or by recollection or by documentation, but just by
reading the code.
Usually code is supposed to implement a design, but here it seems
rather like the design, if there is any, is to be abstracted from the
code.
Maybe I get fascinated too easily.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 12:14 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85fy2y89kb.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 02:12:04PM +0200, David Kastrup wrote:
> Well, that is pretty much exactly what I find fascinating: that the
> behavior is arbitrary and undocumented enough that one can't deduce it
> either by logic or by recollection or by documentation, but just by
> reading the code.
I see your point, but I think you are reading too much into my words. I
am 99% sure that is the way it works (because it would make no sense to
work any other way, and that is my mental model of how it works), but I
am very hesitant to state something outright which I haven't
double-checked in the code. Thus I used weak language.
-Peff
^ permalink raw reply
* Re: way to automatically add untracked files?
From: David Kastrup @ 2007-08-05 12:17 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Shawn O. Pearce, Miles Bader
In-Reply-To: <200708051411.25238.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> 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:
[...]
> 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.
Maybe just git-add -a?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: $GIT_DIR usage
From: Dan Zwell @ 2007-08-05 12:22 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <678E8953ECEB4B72A99DEA2137B05823@ntdev.corp.microsoft.com>
Dmitry Kakurin wrote:
> I think you also need to set GIT_WORK_TREE.
> This way Git will know the root of directories that it controls.
>
> - Dmitry
> ----- Original Message ----- From: "Dan Zwell" <dzwell@gmail.com>
> Newsgroups: gmane.comp.version-control.git
> To: <git@vger.kernel.org>
> Sent: Sunday, 5 August 2007 2:58
> Subject: $GIT_DIR usage
>
>
>> Hi, I had a question about $GIT_DIR. That is to say, it doesn't seem
>> to work. I am using Git 1.5.2.4. See the following: (all the commands
>> I tried besides "git-init" failed).
>>
>> $ export GIT_DIR="`pwd`/.git_public"
>> $ git init
>> warning: templates not found /usr/share//git-core/templates/
>> Initialized empty Git repository in /home/user/temp/.git_public/
>> $ echo > new_file
>> $ git add new_file
>> fatal: add must be run in a work tree
>> $ git commit -a
>> fatal: /usr/bin/git-commit cannot be used without a working tree.
>> $ git commit
>> fatal: /usr/bin/git-commit cannot be used without a working tree.
>> $
>>
>> Is $GIT_DIR not meant to be used this way? Does it have a different
>> purpose / use case, or is this just a bug?
>>
>> Thanks,
>> Dan
>
Thank you. I also had to upgrade Git to the as-yet unreleased version
(this variable doesn't exist in the current stable release), but what
you said makes sense and seems like it should work.
Dan
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-05 12:26 UTC (permalink / raw)
To: Shawn O. Pearce, J. Bruce Fields; +Cc: Git Mailing List
In-Reply-To: <20070804062010.GQ20052@spearce.org>
On Aug 4, 2007, at 8:20 AM, Shawn O. Pearce wrote:
>>
>> 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 partially disagree.
When users start to learn git they are mostly interested in how to
achieve a specific goal, e.g. how to create a commit. I think most
users either accept a command line or a gui, whatever is the easiest
and fastest way to do something.
I strongly believe that the sections in the manual should be organized
along the tasks that users want to solve and discuss available
approaches.
Obviously each chapter should start with simple tasks and simple tools
(the commandline) and only later add advanced usage scenarios. But I
don't think it makes sense to put git gui into a separate chapter.
I personally use the command line for most of my work, but for adding
single diff hunks to the index I use git gui. It's much simple than
'git add -i'.
In the chapter on history browsing, the manual pretty early states
"The best way to see how this works is using the gitk(1) command;
running gitk now on a git repository and looking for merge commits
will help understand how the git organizes history."
which makes absolutely sense to me. If a gui is the best tool to
do the job 'understanding history', then there's no reason to first
restrict the manual to the command line tools, like 'git log'.
Steffen
^ permalink raw reply
* Re: Bootstraper for Git Dev Environment for Windows (Light version)
From: Johannes Schindelin @ 2007-08-05 12:27 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git, Mike Pape, Marius Storm-Olsen, Johannes Sixt
In-Reply-To: <2B8D8540264E4205BD1E4605770422BF@ntdev.corp.microsoft.com>
Hi Dmitry,
[Mike, Marius and Hannes Cc:ed, since I reference their work]
On Sun, 5 Aug 2007, Dmitry Kakurin wrote:
> Please give it a try and tell me how it works for you:
> http://msysgit.googlecode.com/files/GitMe-1.exe (1.6 MB)
That file size is intriguing... And I think you are on a good idea here.
Yesterday I was a bit negative, but after sleeping over it, I think that
you have a point there.
Some comments:
- It works very well! Good job.
- we can have this bootstrap installer, the full package, snapshots
(Marius had this idea, and is probably going to install some cron job
of some sort or other), and an installer without the development
environment (code name WinGit?) for the end user.
- How about calling your package msysGit-netInstall-<version>.exe?
- I'd like to have the full package, too...
- Partly for size reasons (msysGit.exe is an almost self-contained
19MB package, while the pack in the repository is something like
40 MB). But in this sense, I would have to include the pack for
mingw.git as well... Still, on dial-up, 40MB or 60MB makes a
difference, no?
- Partly because I do not like net installers myself... I like to
download a big installer and be done with it.
- There is one big caveat with your bootstrapper: things have been known
to break, and I think msysgit.git is no exception. So I'd like to have
a fallback in case things go awry, also to have something that is tested
(for example, Mike tested msysGit-0.4.exe before releasing it). Of
course, we could solve that issue by branching off of the last release
tag.
- I agree, though, that your approach is more convenient for us.
- Your work is very valuable: it is the first step towards WinGit, because
you already identified some parts that are necessary to run git.
- AFAICT it is possible to make nicer installers with 7-Zip, and also
smaller ones, and most importantly (for me), you can script it. See for
example the script release-msysGit.sh which resides in /bin in
msysgit.git. It's a hands-free no-hassle installer maker.
- my idea is to turn /git into a subproject, but I want to make sure
first, that it works, and that a transition is-subdirectory ->
is-submodule goes smooth. (There is one more submodule that will be
nice to have in msysgit.git... a shell extension similar to TortoiseCVS
is finally gathering way... stay tuned!)
- I wanted to hold off a little, until Hannes can apply the fix-up patch
we need in mingw.git. Because when he does, your bootstrap will run
into problems...
> If we want to stick with this installer here is what we need to do:
> * Remove /git directory from msysGit.git
> * Bring mingw.git up to date so we can remove patching step from installer
Sounds like a plan. Hannes? (I know that Hannes was/is in holiday...)
> To repack just use any compressor that can create SFX archives that can
> also start a file execution. I've used WinRAR. But the whole idea is
> that this bootstrap download should require very little/no tweaking. All
> changes should happen in msysgit.git and mingw.git.
Like I said, I prefer 7-Zip (if only because it is Open Source). It would
be nice to have insight in how you went about to identify what is needed?
Eventually, I'd like to have a script which creates that installer, in
msysgit.git...
Ciao,
Dscho
^ permalink raw reply
* Template commit messages.
From: Thomas Adam @ 2007-08-05 12:32 UTC (permalink / raw)
To: git
Hello all,
Am I correct in thinking that the new template messages that will be
in the up and coming git release will alleviate an "annoyance" I've
currently got with commit messages?
Basically, I want a way of removing what is now, a long list of
untracked files from the commit message before it hits the editor --
I've looked at $GIT_DIR/.git/hooks/{pre,post}-commit as well as:
$GIT_DIR/.git/hooks/commit-msg in the hopes I could add a sed command
there to remove the list of files, and whilst the sed command worked
fine on the command line, adding it to any of those files didn't.
Was this even the right approach? I didn't want to go messing with
git-commit, frankly, so I am hoping that these new templates might
just do the trick.
You might ask why I've got such a large list of untracked files -- the
reason is because I use the same repository to build files in, which
themselves have no need to be added. And whilst I can catch some of
these instances by using .gitignore, it's not enough since not all of
the files have a common extension or anything. And whilst I realise
the list of untracked file is just a friendly warning to me, I find it
annoying and would rather it didn't appear at all if possible, since I
know myself which files need explicitly adding. :)
Hope that makes sense, at least. :)
Kindly,
Thomas Adam
^ permalink raw reply
* Re: $GIT_DIR usage
From: Johannes Schindelin @ 2007-08-05 12:33 UTC (permalink / raw)
To: Dan Zwell; +Cc: git
In-Reply-To: <46B59F63.8020707@gmail.com>
Hi,
On Sun, 5 Aug 2007, Dan Zwell wrote:
> $ export GIT_DIR="`pwd`/.git_public"
> $ git init
> warning: templates not found /usr/share//git-core/templates/
> Initialized empty Git repository in /home/user/temp/.git_public/
I think that you implicitly created a bare repository with that. Just
check if "git config core.bare" returns true.
If so, you need to change that in order to have a working tree.
Hth,
Dscho
^ permalink raw reply
* Re: Bootstraper for Git Dev Environment for Windows (Light version)
From: Dmitry Kakurin @ 2007-08-05 12:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Mike Pape, Marius Storm-Olsen, Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0708051252130.14781@racer.site>
----- Original Message -----
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> - How about calling your package msysGit-netInstall-<version>.exe?
No problem. Feel free to reupload it with a different name.
> mingw.git as well... Still, on dial-up, 40MB or 60MB makes a
> difference, no?
Sorry, I didn't have dialup for years so I don't take it into consideration.
Still 60MB is not that dialup unfriendly.
> - There is one big caveat with your bootstrapper: things have been known
> to break, and I think msysgit.git is no exception. So I'd like to have
> a fallback in case things go awry, also to have something that is tested
> (for example, Mike tested msysGit-0.4.exe before releasing it). Of
> course, we could solve that issue by branching off of the last release
> tag.
That, or better yet always maintain master branch in a working condition. Seriously.
If it (VERY rarely) breaks we'll just revert the offending checkin to bring it back in shape.
Where I come from, 'main' or 'master' should ALWAYS be functional.
> - AFAICT it is possible to make nicer installers with 7-Zip, and also
I have no preference here. I just use what I know (WinRAR).
If you feel strongly about 7zip (which I can see you do for some reason :-) feel free to repackage it.
> - I wanted to hold off a little, until Hannes can apply the fix-up patch
> we need in mingw.git. Because when he does, your bootstrap will run
> into problems...
Not sure why...
> It would
> be nice to have insight in how you went about to identify what is needed?
Well, I've set path to a single directory (C:\GitMe\bin), copies over bash and git-clone
and started running it until it worked. Which happened surprisingly fast.
- Dmitry
^ permalink raw reply
* [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-08-05 12:59 UTC (permalink / raw)
To: bfields, gitster, git; +Cc: Steffen Prohaska
In-Reply-To: <20070803125634.GB28323@fieldses.org>
git gui is especially useful because it allows to select diff hunks.
Now it is briefly mentioned in the user-manual.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0071cd0..6865d21 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1079,6 +1079,17 @@ $ git diff HEAD # difference between HEAD and working tree; what
$ git status # a brief per-file summary of the above.
-------------------------------------------------
+Another approach for creating commits is git gui:
+
+-------------------------------------------------
+$ git gui citool
+-------------------------------------------------
+
+starts the commit tool, which lets you add files (use menu
+'Commit > Stage to Commit') or individually diff hunks (use
+'Stage Hunk For Commit' in the context menu of the diff view)
+to the index.
+
[[creating-good-commit-messages]]
Creating good commit messages
-----------------------------
@@ -2482,6 +2493,10 @@ applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit
--amend.
+git gui is especially useful to rework commits as it lets you
+selectively add single diff hunks to the index (use
+'Stage Hunk For Commit' in the context menu of the diff view).
+
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.rc3.151.g8d6306
^ permalink raw reply related
* Re: $GIT_DIR usage
From: Dan Zwell @ 2007-08-05 13:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708051332230.14781@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Dan Zwell wrote:
>
>> $ export GIT_DIR="`pwd`/.git_public"
>> $ git init
>> warning: templates not found /usr/share//git-core/templates/
>> Initialized empty Git repository in /home/user/temp/.git_public/
>
> I think that you implicitly created a bare repository with that. Just
> check if "git config core.bare" returns true.
>
> If so, you need to change that in order to have a working tree.
>
> Hth,
> Dscho
>
>
You are exactly right, I accidentally created a bare repository. I can
do 2 things: I can change core.bare to true, or I can create .git in the
normal way, then move rename it. Both things still have the problem of
git not knowing where the working directory is. Is the only way to fix
this in 1.5.2.4, or is my only option to upgrade?
Thanks,
Dan
^ permalink raw reply
* Re: [PATCH] Fix install-doc-quick target
From: Johannes Schindelin @ 2007-08-05 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Mark Levedahl, Git Mailing List
In-Reply-To: <7vmyx6fohv.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Aug 2007, Junio C Hamano wrote:
> * I am getting the impression that the semantics of the updated
> work-tree support is as broken as the original, although the
> code that implements it is easier to read.
>
> Admittedly, this is an unorthodox corner case usage, that
> deals with a tree structure that does not have any relation
> with the current project state, and the script is started
> with a subdirectory of the current project.
I do not like the behaviour "be stupid and assume cwd to be the working
tree root, if GIT_DIR is set and GIT_WORK_TREE is not".
It bears _all_ kind of stupid connotations. Just imagine what would
happen with "git --git-dir=. add .".
IMHO the new behaviour is _better_, since you can not shoot yourself in
the foot so easily. Being able to safeguard against doing a work tree
operation inside the git directory is a direct and elegant consequence of
defaulting to $GIT_DIR/.. in case $GIT_DIR ends in "/.git", and no work
tree if $GIT_DIR does _not_ end in "/.git".
The semantics "if GIT_DIR is set, just assume the cwd to be the work tree
root unilaterally" is _broken_ as far as I am concerned.
NOTE: this change in semantics will _only_ _ever_ burn you if you set
GIT_DIR, but not GIT_WORK_TREE, in a _subdirectory_ of $GIT_DIR/.. (if it
ends in /.git, and $GIT_DIR otherwise).
So the _common_ use of setting GIT_DIR, namely something like
$ git --git-dir=/some/where/completely/different bla
is _not_ affected.
So I really think that the code in install-doc-quick.sh is not only ugly,
but also wrong. It sets the GIT_DIR to _the same_ value as the default,
to change git's idea of the _work tree_! All at the same time as it is
utterly clear that it wants to write to $HOME/share/man, but it does not
make this its working tree. No, sir. It has to play cute games with the
prefix.
However, you are the maintainer, and it is your decision. If you want the
old semantics (without sanity checks for work-tree operations inside the
git directory), here is a patch. I don't like it, but if you take it,
I'll learn to live with it.
Ciao,
Dscho
-- snipsnap --
Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unset
The old behaviour was to unilaterally default to the cwd is the work tree
when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside
the GIT_DIR, or if GIT_DIR is actually something like ../../../.git.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Feel free to change the commit message.
setup.c | 50 +++++++++-----------------------------------------
1 files changed, 9 insertions(+), 41 deletions(-)
diff --git a/setup.c b/setup.c
index 4945eb3..7bcf4eb 100644
--- a/setup.c
+++ b/setup.c
@@ -189,53 +189,21 @@ int is_inside_work_tree(void)
}
/*
- * If no worktree was given, and we are outside of a default work tree,
- * now is the time to set it.
- *
- * In other words, if the user calls git with something like
- *
- * git --git-dir=/some/where/else/.git bla
- *
- * default to /some/where/else as working directory; if the specified
- * git-dir does not end in "/.git", the cwd is used as working directory.
+ * set_work_tree() is only ever called if you set GIT_DIR explicitely.
+ * The old behaviour (which we retain here) is to set the work tree root
+ * to the cwd, unless overridden by the config, the command line, or
+ * GIT_WORK_TREE.
*/
const char *set_work_tree(const char *dir)
{
- char dir_buffer[PATH_MAX], *rel = NULL;
- static char buffer[PATH_MAX + 1];
- int len, suffix_len = strlen(DEFAULT_GIT_DIR_ENVIRONMENT) + 1;
-
- /* strip the variable 'dir' of the postfix "/.git" if it has it */
- len = strlen(dir);
- if (len > suffix_len &&
- !strcmp(dir + len - suffix_len, "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
- if ((len - suffix_len) >= sizeof(dir_buffer))
- die("directory name too long");
- memcpy(dir_buffer, dir, len - suffix_len);
- dir_buffer[len - suffix_len] = '\0';
-
- /* are we inside the default work tree? */
- rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
- }
+ char buffer[PATH_MAX + 1];
- /* if rel is set, the cwd is _not_ the current working tree */
- if (rel && *rel) {
- if (!is_absolute_path(dir))
- set_git_dir(make_absolute_path(dir));
- dir = dir_buffer;
- if (chdir(dir))
- die("cannot chdir to %s: %s", dir, strerror(errno));
- else
- strcat(rel, "/");
- inside_git_dir = 0;
- } else {
- rel = NULL;
- dir = getcwd(buffer, sizeof(buffer));
- }
- git_work_tree_cfg = xstrdup(dir);
+ if (!getcwd(buffer, sizeof(buffer)))
+ die ("Could not get the current working directory");
+ git_work_tree_cfg = xstrdup(buffer);
inside_work_tree = 1;
- return rel;
+ return NULL;
}
/*
^ permalink raw reply related
* Re: GIT push to sftp (feature request)
From: Johannes Schindelin @ 2007-08-05 13:38 UTC (permalink / raw)
To: pavlix; +Cc: git
In-Reply-To: <200708051105.44376.pavlix@pavlix.net>
Hi,
On Sun, 5 Aug 2007, pavlix wrote:
> Git would also have to be able to create a remote repository (maybe an option
> to push?).
>
> Did I miss something?
Yes.
First, we do not allow remote repository initialising yet.
Second, if you do not have git installed on the remote host, you probably
want to serve via http. This is a very suboptimal transport, as it cannot
repack the contents.
And if you use such a suboptimal transport, people will blame _git_ for
being slow, even if you made it slow deliberately.
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Josef Sipek @ 2007-08-05 13:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20070805023130.GV20052@spearce.org>
On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:
...
[rebase is complex but fun]
Great, but does git have something that could replace
$QUILT_LIKE_APP refresh?
Sure, if you can take 2 commits and collapse them into one you could fake it
by creating a dummy commit with the new changes, and then collapsing, but
that's nasty - and reflog might not like that much :)
Josef 'Jeff' Sipek.
--
I'm somewhere between geek and normal.
- Linus Torvalds
^ permalink raw reply
* Re: $GIT_DIR usage
From: Johannes Schindelin @ 2007-08-05 13:41 UTC (permalink / raw)
To: Dan Zwell; +Cc: git
In-Reply-To: <46B5CA50.3050500@gmail.com>
Hi,
On Sun, 5 Aug 2007, Dan Zwell wrote:
> I can do 2 things: I can change core.bare to true, or I can create .git
> in the normal way, then move rename it. Both things still have the
> problem of git not knowing where the working directory is. Is the only
> way to fix this in 1.5.2.4, or is my only option to upgrade?
I really have to ask now: why is ./.git/ not an appropriate name?
Ciao,
Dscho
^ permalink raw reply
* Re: Bootstraper for Git Dev Environment for Windows (Light version)
From: Johannes Schindelin @ 2007-08-05 13:51 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git, Mike Pape, Marius Storm-Olsen, Johannes Sixt
In-Reply-To: <26F4E92272F14115959CFA0C23809617@ntdev.corp.microsoft.com>
Hi,
On Sun, 5 Aug 2007, Dmitry Kakurin wrote:
> ----- Original Message ----- From: "Johannes Schindelin"
> <Johannes.Schindelin@gmx.de>
>
>
> > - How about calling your package msysGit-netInstall-<version>.exe?
> No problem. Feel free to reupload it with a different name.
I'll do so later... When it has to change.
> > mingw.git as well... Still, on dial-up, 40MB or 60MB makes a
> > difference, no?
>
> Sorry, I didn't have dialup for years so I don't take it into
> consideration. Still 60MB is not that dialup unfriendly.
Okay.
> > - There is one big caveat with your bootstrapper: things have been
> > known to break, and I think msysgit.git is no exception. So I'd like
> > to have a fallback in case things go awry, also to have something that
> > is tested (for example, Mike tested msysGit-0.4.exe before releasing
> > it). Of course, we could solve that issue by branching off of the
> > last release tag.
>
> That, or better yet always maintain master branch in a working
> condition. Seriously. If it (VERY rarely) breaks we'll just revert the
> offending checkin to bring it back in shape. Where I come from, 'main'
> or 'master' should ALWAYS be functional.
Okay, let's try to be anal then.
> > - AFAICT it is possible to make nicer installers with 7-Zip, and also
>
> I have no preference here. I just use what I know (WinRAR). If you feel
> strongly about 7zip (which I can see you do for some reason :-) feel
> free to repackage it.
Yeah ;-) I like it because it is Open Source... and easily scriptable.
Even if you want to make a graphical installer.
> > - I wanted to hold off a little, until Hannes can apply the fix-up
> > patch we need in mingw.git. Because when he does, your bootstrap will
> > run into problems...
>
> Not sure why...
Neither am I anymore.
What would you say about this idea:
- upload a branch "mingw-devel" to msysgit.git, which is identical to
mingw.git's devel, plus our patches.
- convert /git to a submodule, fetching from msysgit.git's mingw-devel
branch.
- adjust /etc/profile for the changes.
- make a new net installer and upload it.
- But keep doing some full releases in the meantime, which do not clone
anything, but rather initialise /git/.git so that people can send in
patches?
> > It would be nice to have insight in how you went about to identify
> > what is needed?
>
> Well, I've set path to a single directory (C:\GitMe\bin), copies over
> bash and git-clone and started running it until it worked. Which
> happened surprisingly fast.
Ah, thanks. Valuable work, this.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-05 13:55 UTC (permalink / raw)
To: Junio C Hamano, Lars Hjemli; +Cc: git, Eran Tromer
In-Reply-To: <7v643vj316.fsf@assigned-by-dhcp.cox.net>
On Fri, Aug 03, 2007 at 10:13:09PM -0700, Junio C Hamano wrote:
> Let me understand the problem first. If your first checkout
> does not check out the submodule, switching between revisions
> that has different commit of the submodule there would not fail,
> but once you checkout the submodule, switching without updating
> the submodule would be Ok (because by design updating the
> submodule is optional) but then further switching out of that
> state will fail because submodule in the supermodule tree and
> checked-out submodule repository are now out of sync. Is that
> the problem?
Yes.
> In any case, I doubt ce_compare_gitlink() is the right layer to
> work this around -- it is not about "can we switch" but is about
> "is it different". It is at too low a level.
You are right. I followed the logic down to ce_compare_gitlink,
but I should have backed up again.
> The current policy is to consider it is perfectly normal that
> checked-out submodule is out-of-sync wrt the supermodule index,
> if I am reading you right. I think it is a good policy, at
> least until we introduce a superproject repository configuration
> option that says "in this repository, I do care about this
> submodule and at any time I move around in the superproject,
> recursively check out the submodule to match". The most extreme
> case of this policy is that the superproject index knows about
> the submodule but the subdirectory does not even have to be
> checked out, which is what we have now.
Yes. Alex Riesen convinced me that having the submodule checked
out is a good indication that you care about the submodule being
in sync (although you then apparently convinced him that this is
not a good idea). You didn't take any patch that implements this
yet, so I'll probably try again after you release 1.5.3.
Since some people seem to like the current situation, I'd only do
the updating of checked-out submodules if some "autoUpdateSubmodules"
is set.
> How about doing something like this instead?
Works like a charm.
On Sat, Aug 04, 2007 at 01:41:06PM +0200, Lars Hjemli wrote:
> Btw: I've applied your patch to rc-4 and tested the result in my cgit
> repo: very nice, and very ack'd ;-)
If it matters, a definite
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
too.
skimo
^ permalink raw reply
* Re: Some ideas for StGIT
From: Johannes Schindelin @ 2007-08-05 13:56 UTC (permalink / raw)
To: Josef Sipek; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <20070805133940.GA18835@filer.fsl.cs.sunysb.edu>
Hi,
On Sun, 5 Aug 2007, Josef Sipek wrote:
> On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:
> ...
> [rebase is complex but fun]
>
> Great, but does git have something that could replace
> $QUILT_LIKE_APP refresh?
What does "refresh"? (I never used quilt, and probably never will, since
rebase -i does what I need.)
> Sure, if you can take 2 commits and collapse them into one you could
> fake it by creating a dummy commit with the new changes, and then
> collapsing, but that's nasty - and reflog might not like that much :)
IIUC you want to edit/amend a patch in the middle of a series? Two ways
to go about it:
1) (preferred)
* start rebase -i
* mark the commit as "edit"
* wait until rebase stops to let you edit it
* edit, test, commit --amend
* rebase --continue
2) (not so preferred, but often convenient)
* fix bug
* commit with a dummy message
* rebase -i
* move commit just after the commit-to-edit
* mark second as "squash"
* when the editor comes up, just delete the second
commit's message, and possibly adjust the first's
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