* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Johan Herland @ 2007-05-10 22:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070510220253.GZ13719@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Friday 11 May 2007, J. Bruce Fields wrote:
> On Thu, May 10, 2007 at 11:53:31PM +0200, Johan Herland wrote:
> > Use git-config for setting global user.name and user.email rather than
> > telling the user to edit ~/.gitconfig directly. This brings
> > user-manual.txt in line with tutorial.txt.
>
> The inconsistency is intentional. We want users to know about
> git-config, because it's helpful when writing scripts, and because it
> has a useful manpage. But we also want them to know about the
> config-file syntax, since most of us find reading and editing a file
> more intuitive than running git-config. So we use a mixture of both.
I see your point, but when I look at the user manual, the only place I can
actually find git-config used is in [[remote-branch-configuration]].
Besides, we also present the config-file syntax for user.{name,email} in
[[telling-git-your-name]], so it's not like I'm remove every reference to
the layout of .gitconfig.
Maybe we can present both versions in [[making-changes]]?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Correct error message in revert/cherry-pick
From: Shawn O. Pearce @ 2007-05-10 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We now write to MERGE_MSG, not .msg. I missed this earlier
when I changed the target we write to.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 55d4fa1..ea2f15b 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -133,7 +133,7 @@ static void add_to_msg(const char *string)
{
int len = strlen(string);
if (write_in_full(msg_fd, string, len) < 0)
- die ("Could not write to .msg");
+ die ("Could not write to MERGE_MSG");
}
static void add_message_to_msg(const char *message)
--
1.5.2.rc2.754.g40686
^ permalink raw reply related
* [PATCH] Document 'git-log --decorate'
From: Michael Hendricks @ 2007-05-10 22:09 UTC (permalink / raw)
To: git
Signed-off-by: Michael Hendricks <michael@ndrix.org>
---
Documentation/git-log.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 49bb539..dd06527 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -51,6 +51,9 @@ include::pretty-formats.txt[]
a record about how the tip of a reference was changed.
See also gitlink:git-reflog[1].
+--decorate::
+ Print out the ref names of any commits that are shown.
+
<paths>...::
Show only commits that affect the specified paths.
--
1.5.2.rc2
^ permalink raw reply related
* Re: quick bare clones taking longer?
From: Dan Nicholson @ 2007-05-10 22:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqgsibrr.fsf@assigned-by-dhcp.cox.net>
On 5/10/07, Junio C Hamano <junkio@cox.net> wrote:
> Dan Nicholson <dbn.lists@gmail.com> writes:
>
> > In fact, all POSIX shells should support `cd -P' according to the spec, so it
> > should probably just be used directly instead of hoping that /bin/pwd exists.
> >
> > (cd -P "$1" && (cd .git ; pwd)) 2>/dev/null
> >
> > http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html
>
> Yes but no ;-). I've said this a few times on the list in the
> past, but I'll repeat it again for new people.
>
> We reject something whose portability in question by saying
> "It's not _even in_ POSIX". We on the other hand try to refrain
> from saying "POSIX says you are supposed to have it, so screw
> people that are not fully POSIX".
Yes, I suppose. At the same time, git already implicitly requires more
than, say, a Bourne shell. Functions, $( ) command substitution, ${}
parameter expansion, $(( )) arithmetic expansion, etc. These are all
standard in a POSIX shell, but may or may not exist in other shell
variants.
--
Dan
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Shawn O. Pearce @ 2007-05-10 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Petr Baudis, Martin Langhoff, git
In-Reply-To: <7vzm4dplhu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > And unlike the "simpler" model of committing individual hunks
> > with "git add -i" or something like that, my model is actually
> > much superior!
>
> I obviously agree with this. As I said a few times I regret
> introducing "add -i" --- it encourages a wrong workflow, in that
> what you commit in steps never match what you had in the working
> tree and could have tested until the very end.
Which is why I'm considering shelving support (of some kind) in
git-gui... but I'm probably not going to take away the current
index view, nor am I going to take away the current hunk selection.
But I would like to make it easier for non-patching-editing gods
(Linus) to pull hunks in from a shelf, test them, and commit them.
Said shelf probably would be another branch, much as Linus' nicely
documented workflow does...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Junio C Hamano @ 2007-05-10 22:04 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705102353.31821.johan@herland.net>
I think this was rejected before, and the reason was that the
point of this section is to make users aware that what novices
might think is internal is actually represented in a very simple
to understand and simple to change format, and reassure people
that making small mistakes can be fixed with an editor.
And I think that reasoning still stands.
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Shawn O. Pearce @ 2007-05-10 22:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Alex Riesen, Git Mailing List, Linus Torvalds
In-Reply-To: <7vmz0dmb2u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * git-rebase with -m is dog slow. There were people who
> advocated to make it the default, but they probably are
> either working in a very small project, or working on a
> filesystem that even git-apply is slow that the speed
> difference does not matter to them.
That would have been me saying make -m default. Because on git.git
I don't really see a huge performance difference on my Mac, and the
bigger projects that I work on are on Cygwin, where *everything*
is slow as hell.
The few places there that I do need rebase, I actually also need
the rename detection that am -3 or rebase -m would do, so I just
wind up paying the penalty anyway. Or really I just get burned
because I run the op without the magic "do what I really need"
flag, and it dies, and I have to reset and start it again, which
just takes longer than if -3 or -m was the default.
But that's not the situation everyone else has, so its reasonable
that -m ain't the default. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: J. Bruce Fields @ 2007-05-10 22:02 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705102353.31821.johan@herland.net>
On Thu, May 10, 2007 at 11:53:31PM +0200, Johan Herland wrote:
> Use git-config for setting global user.name and user.email rather than
> telling the user to edit ~/.gitconfig directly. This brings
> user-manual.txt in line with tutorial.txt.
The inconsistency is intentional. We want users to know about
git-config, because it's helpful when writing scripts, and because it
has a useful manpage. But we also want them to know about the
config-file syntax, since most of us find reading and editing a file
more intuitive than running git-config. So we use a mixture of both.
--b.
> Signed-off-by: Johan Herland <johan@herland.net>
> ---
> Documentation/user-manual.txt | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/user-manual.txt
> b/Documentation/user-manual.txt
> index 13db969..23e2f45 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -158,11 +158,8 @@ Making changes
> Make sure git knows who to blame:
>
> ------------------------------------------------
> -$ cat >>~/.gitconfig <<\EOF
> -[user]
> - name = Your Name Comes Here
> - email = you@yourdomain.example.com
> -EOF
> +$ git config --global user.name "Your Name Comes Here"
> +$ git config --global user.email you@yourdomain.example.com
> ------------------------------------------------
>
> Select file contents to include in the next commit, then make the
> --
> 1.5.0.7
>
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-10 21:55 UTC (permalink / raw)
To: Dan Nicholson; +Cc: git
In-Reply-To: <loom.20070510T224750-851@post.gmane.org>
Dan Nicholson <dbn.lists@gmail.com> writes:
> In fact, all POSIX shells should support `cd -P' according to the spec, so it
> should probably just be used directly instead of hoping that /bin/pwd exists.
>
> (cd -P "$1" && (cd .git ; pwd)) 2>/dev/null
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html
Yes but no ;-). I've said this a few times on the list in the
past, but I'll repeat it again for new people.
We reject something whose portability in question by saying
"It's not _even in_ POSIX". We on the other hand try to refrain
from saying "POSIX says you are supposed to have it, so screw
people that are not fully POSIX".
^ permalink raw reply
* [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Johan Herland @ 2007-05-10 21:53 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Use git-config for setting global user.name and user.email rather than
telling the user to edit ~/.gitconfig directly. This brings
user-manual.txt in line with tutorial.txt.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/user-manual.txt | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt
b/Documentation/user-manual.txt
index 13db969..23e2f45 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -158,11 +158,8 @@ Making changes
Make sure git knows who to blame:
------------------------------------------------
-$ cat >>~/.gitconfig <<\EOF
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
-EOF
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
Select file contents to include in the next commit, then make the
--
1.5.0.7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: quick bare clones taking longer?
From: Dan Nicholson @ 2007-05-10 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <4642DE52.F9F0A5B2@eudaptics.com>
Johannes Sixt <J.Sixt <at> eudaptics.com> writes:
>
> Matthieu Moy wrote:
> >
> > Junio C Hamano <junkio <at> cox.net> writes:
> >
> > > get_repo_base() {
> > > - (cd "$1" && (cd .git ; pwd)) 2> /dev/null
> > > + (
> > > + cd "`/bin/pwd`" &&
> > > + cd "$1" &&
> > > + (
> > > + cd .git
> > > + pwd
> > > + )
> > > + ) 2>/dev/null
> > > }
> >
> > Will this work on windows?
>
> Yes. As does the alternative that uses cd -P. MinGW uses bash (3.1
> here).
In fact, all POSIX shells should support `cd -P' according to the spec, so it
should probably just be used directly instead of hoping that /bin/pwd exists.
(cd -P "$1" && (cd .git ; pwd)) 2>/dev/null
http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html
--
Dan
^ permalink raw reply
* Re: Using StGIT for tweaking already-committed stuff
From: Carl Worth @ 2007-05-10 21:16 UTC (permalink / raw)
To: Petr Baudis
Cc: J. Bruce Fields, Linus Torvalds, Johannes Sixt, catalin.marinas,
git
In-Reply-To: <20070510200253.GD4489@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Thu, 10 May 2007 22:02:53 +0200, Petr Baudis wrote:
>
> I'm sorry, I couldn't parse this. :-)
>
I'll try again.
I like the git user interface. I like it a lot. (It's got a couple of
tiny things that I would do differently if I could start over, but
more importantly it has a lot of big things that I wouldn't have even
thought of if I had started from scratch.)
But with respect to the current topic, there are a couple of features
that the git interface is missing compared to something like stg:
1. Amend a commit that's somewhere besides the tip of a branch,
(rebuilding every commit that follows)
2. Re-ordering commits that exist on a branch, (again, rebuilding
every commit that follows).
And what I was trying to say in my confusing paragraph, is that if I
look to stg to add one or both pieces of this functionality, then it
comes with a lot of baggage. For example, "stg --help" lists about 38
sub-commands. And some of those are wholly unnecessary if already
using git, (4 repository commands 6 working-copy commands, for
example). While others exist only to allow a notion of "git commits"
vs. "stg commits" and translating back and forth between them,
(assimilate and uncommit for example).
Now, that's not a critique of stg itself. As you say, it can work
really well if you use it in a standalone fashion to track some
project.
I'd just love to see something more minimal, and incorporated into git
itself, to address the missing functionality. Right now, "cherry-pick
A..B" is all I have to suggest. But maybe later there could be some
sort of push/pop addition as well, (except that obviously the name
"push" isn't available as a sub-command).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-10 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, J. Bruce Fields, barkalow, git
In-Reply-To: <7vtzukif5t.fsf@assigned-by-dhcp.cox.net>
On 2007-05-10 13:42:38 -0700, Junio C Hamano wrote:
> Other than that, I think this is well written, and if everybody
> thinks it should be in the user's manual, I am fine with it.
One "hacking howto" chapter at the end of the user's manual seems
perfectly fine to me too. We'll just have to remember to split it out
into a manual of its own if it grows too large for one chapter.
It's the potted plant strategy. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] t5000: skip ZIP tets when unzip is absent
From: Junio C Hamano @ 2007-05-10 20:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0705101246430.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> t/t5000-tar-tree.sh | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index e223c07..1580592 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -108,6 +108,13 @@ test_expect_success \
> 'git-archive --format=zip' \
> 'git-archive --format=zip HEAD >d.zip'
>
> +unzip -v 2>/dev/null
> +if [ $? -ne 10 ]; then
> + echo "Skipping ZIP tests, because unzip was not found"
> + test_done
> + exit
> +fi
> +
Are you sure about this?
$ unzip -v 2>/dev/null; echo "**$?**"
UnZip 5.52 of 28 February 2005, by Debian. Original by Info-ZIP.
Latest sources and executables are at
ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other
sites.
Compiled with gcc 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)
for Unix (Linux ELF) on Aug 30 2006.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not
supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method
supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.9 of 05 May 2000]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]
**0**
$ unzil -v 2>/dev/null; echo "**$?**"
**127**
So two points are...
* 2>/dev/null alone would give unsightly output to stdout which
does not need to be in the test when unzip is available;
* at least one version of unzip does not exit with status 10
upon successful -v invocation, so the test is wrong; "unzip
is unavaiable" is typically signalled with exit 127 (POSIX
tells shell to use this for "command not found"; if found but
not executable is 126).
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Junio C Hamano @ 2007-05-10 20:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J. Bruce Fields, kha, barkalow, git
In-Reply-To: <Pine.LNX.4.64.0705101233580.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 13db969..3c3f1b4 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3160,6 +3160,225 @@ confusing and scary messages, but it won't actually do anything bad. In
> contrast, running "git prune" while somebody is actively changing the
> repository is a *BAD* idea).
>
> +[[birdview-on-the-source-code]]
> +A birdview on Git's source code
> +-----------------------------
Perhaps two dashes too short here...
> +
> +While Git's source code is quite elegant, it is not always easy for
> +new developers to find their way through it. A good idea is to look
> +at the contents of the initial commit:
> +_e83c5163316f89bfbde7d9ab23ca2e25604af290_ (also known as _v0.99~954_).
I am not sure we would need to say "is quite elegant". Why
don't we be blunt and say "It is not always easy for ...". That
holds true for any project of nontrivial size. I would rewrite
the first part like this.
It is not always easy for new developers to find their
way through Git's source code. This section gives you a
gentle guidance to show where to start.
A good place to start is to look at the contents of the
initial commit, with this command:
----------------------------------------------------------------
$ git checkout e83c516
----------------------------------------------------------------
and would not bore users with v0.99~954 or "git show" details.
"git show" to inspect one file at a time is not a good way to
get the feel of unknown set of source files, even though it is
very handy once you know where things were. And then continue
on to this part...
> +Be sure to read the README in that revision _after_ you are familiar with
> +the terminology (<<glossary>>), since the terminology has changed a little
> +since then. For example, we call the things "commits" now, which are
> +described in that README as "changesets".
> +
> +Actually a lot of the structure as it is now can be explained by that
> +initial commit.
It is also worth to point out that the initial revision, while
laying the foundation of almost every important factor of git we
have today, is small enough for reading everything in one
sitting, probably upfront, instead of making it a parenthesized
comment in a later paragraph. If somebody wants to dive into
git development to take a source-code tour, it is not really "it
will help you", but is a small enough required investment of
time.
> +For example, we do not call it "cache" any more, but "index", however, the
> +file is still called `cache.h`. Remark: Not much reason to change it now,
> +especially since there is no good single name for it anyway, because it is
> +basically _the_ header file which is included by _all_ of Git's C sources.
> +
> +If you grasp the ideas in that initial commit (it is really small and you
> +can get into it really fast, and it will help you recognize things in the
> +much larger code base we have now), you should go on skimming `cache.h`,
> +`object.h` and `commit.h` in the current version.
Other than that, I think this is well written, and if everybody
thinks it should be in the user's manual, I am fine with it.
By the way, when I sent the outline of hacker's manual as a
follow-up to the discussion, I think I forgot to properly say
this, so here it is: Thanks for starting the bird's eye view.
^ permalink raw reply
* Re: Merging commits together into a super-commit
From: Robin Rosenberg @ 2007-05-10 20:29 UTC (permalink / raw)
To: Carl Worth
Cc: Petr Baudis, J. Bruce Fields, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <87tzuk31fu.wl%cworth@cworth.org>
torsdag 10 maj 2007 skrev Carl Worth:
> But there are still some places where an experienced git user runs
> into some awkward situations trying to use stg. For example, "stg
> refresh" is basically always doing the equivalent of "commit -a" so
> there's annoyingly no way to refresh only some of the modified state
> into the commit.
List the files to refresh and you get what you want.
stg refresh file1 file2...
> Also, if I want to edit a commit message while under the influence of
> stg, how do I do that? If I do "git commit --amend" will I seriously
> confuse stg, (I'm guessing I would, but I don't know).
stg refresh -e
[...]
> Plus, all the stuff that stg provides to allow it to be used
> standalone ends up just being noise to the git user that just wants to
> do some stack-based manipulation of an unpublished branch, for
> example.
>
> So, I'd really like to see something more integrated into git itself
> that provides some of the missing functionality.
I agree mixing stgit and git is not really comfy until you learn it and still
I mess things up somtimes. Also rebase seems quite a bit faster than stgit, but I
have not intuitive understanding for rebase so I get scared everytime. Having
a gui that lets me mark commits and "drag" them to the new location would
be nice.
-- robin
^ permalink raw reply
* Re: Switching branch before commit
From: Junio C Hamano @ 2007-05-10 20:08 UTC (permalink / raw)
To: Ron Parker; +Cc: git
In-Reply-To: <769697AE3E25EF4FBC0763CD91AB1B0201D496E7@MBGMail01.mobot.org>
"Ron Parker" <ron.parker@mobot.org> writes:
> I know this is probably a FAQ and I thought I found it somewhere once,
> but... How do I commit changes from in my working directory to another
> (possibly non-existent) branch?
>
> All too often I am working on changes and realize I am sitting on master
> or a topic branch and I need to commit my mods to different branch. I
> really don't like:
>
> git commit
> git branch <other-branch>
> git reset --hard HEAD^
I do not like that either, and I wouldn't do that. In fact that
would not work, as "git branch" would not switch to the other
branch you just created.
I would do:
$ git checkout -b other-branch
which would create and switch to other-branch, based on the
current HEAD (in your case, 'master'), WITHOUT disrupting what
is in your working tree and the index.
and then (perhaps after working on it some more to perfection):
$ git commit
to commit that work I (mistakenly) started on 'master' in that
other branch. Then I would come back to master:
$ git checkout master
^ permalink raw reply
* Using StGIT for tweaking already-committed stuff
From: Petr Baudis @ 2007-05-10 20:02 UTC (permalink / raw)
To: Carl Worth
Cc: J. Bruce Fields, Linus Torvalds, Johannes Sixt, catalin.marinas,
git
In-Reply-To: <87tzuk31fu.wl%cworth@cworth.org>
On Thu, May 10, 2007 at 09:48:05PM CEST, Carl Worth wrote:
> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:
> > stg uncommit -n N
> > stg pop -n N-1
> > ..hack..
> > stg refresh
> > stg push -a
> >
> > It seems to be a bit shorter than the sequence you've presented above,
> > and overally working with volatile commits using StGIT feels much more
> > natural to me - and I haven't even ever used quilt seriously! (I have
> > special antipathy to the git reset UI, too.)
>
> The -n option is something I hadn't noticed, and that helps, (except
> that what I've got to start with is a git revision name, not a
> number).
Hmm, yes, I've been thinking myself that it would be quite nice if I
could just tell uncommit git revname right away.
> But there are still some places where an experienced git user runs
> into some awkward situations trying to use stg. For example, "stg
> refresh" is basically always doing the equivalent of "commit -a" so
> there's annoyingly no way to refresh only some of the modified state
> into the commit.
Yes, I fear that StGIT hides the index in a similar way that Cogito
does. It seems like user index usage is undergoing kind of renaissance
these days in Git community (at least it seems to me this way, maybe
it's always been this way), it would probably make sense to allow making
use of index in StGIT as well.
> Also, if I want to edit a commit message while under the influence of
> stg, how do I do that? If I do "git commit --amend" will I seriously
> confuse stg, (I'm guessing I would, but I don't know).
I have no idea, but there's stg refresh -e.
> It's that kind of uncertainty that makes me uncomfortable to mix git
> and stg. And personally, I couldn't get excited about using it alone,
> (for example, in addition to the commit message with headline, stg
> makes me invent yet _another_ name for every commit---yuck). Not to
> mention I'm already quite comfortable with git alone, and all the
> flexibility it provides.
I wouldn't normally use it for projects I have commit access to myself,
but for maintaining own patches for an "external" project, I just find
it much more comfortable than using git. But then again, if this part of
git UI improved as much as some of the other parts in the last half a
year...
And yes, it would be cool if stg new could guess patch name from the
subject line in a similar manner that stg uncommit does.
> Plus, all the stuff that stg provides to allow it to be used
> standalone ends up just being noise to the git user that just wants to
> do some stack-based manipulation of an unpublished branch, for
> example.
I'm sorry, I couldn't parse this. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-10 20:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Daniel Barkalow, J. Bruce Fields, Petr Baudis, junio, git
In-Reply-To: <Pine.LNX.4.64.0705100015120.4167@racer.site>
On 2007-05-10 00:23:50 +0200, Johannes Schindelin wrote:
> I was not aware originally, that no arithmetic is involved in SHA-1
> computation.
>
> If you store large integers, it makes tons of sense to follow the
> endianness, especially if you do _both_ boolean and integer
> operations on them.
Actually, if you take a look at
http://en.wikipedia.org/wiki/Sha1#SHA-1_algorithm
you'll see that in addition to an unholy mess of bitwise operations,
it does do some additions, on 32-bit big-endian words according to the
article.
But thinking of them as addition gives you the wrong mental picture;
they're simply one of many ways for a standard processor to mix bits
efficiently as far as SHA-1 is concerned. The algorithm is specified
as yielding a 160-bit binary blob, and can and should be thought of as
a black NSA-certified box with "warranty void if this seal is broken"
stickers. (Unless you're the one implementing it, of course. But then
you know what you're doing.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Switching branch before commit
From: Adam Roben @ 2007-05-10 20:02 UTC (permalink / raw)
To: Ron Parker; +Cc: git
In-Reply-To: <769697AE3E25EF4FBC0763CD91AB1B0201D496E7@MBGMail01.mobot.org>
On May 10, 2007, at 12:43 PM, Ron Parker wrote:
> I know this is probably a FAQ and I thought I found it somewhere once,
> but... How do I commit changes from in my working directory to another
> (possibly non-existent) branch?
>
> All too often I am working on changes and realize I am sitting on
> master
> or a topic branch and I need to commit my mods to different branch. I
> really don't like:
>
> git commit
> git branch <other-branch>
> git reset --hard HEAD^
>
> Is there anything like:
> git commit -b <other-branch> [<file>...]?
>
> If not, would patches to implement such a change be accepted?
You can do this simply by doing the following:
git checkout -b <other-branch>
git commit
The changes in your working tree will be carried over to <other-
branch> when you do the git-checkout command.
-Adam
^ permalink raw reply
* Re: Merging commits together into a super-commit
From: J. Bruce Fields @ 2007-05-10 19:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20070510194742.GC4489@pasky.or.cz>
On Thu, May 10, 2007 at 09:47:42PM +0200, Petr Baudis wrote:
> Actually, you don't have to - if you don't specify the patch names,
> stgit will make them up itself using the subject of the commit message
> as a base.
You still have to on new patches, right?
> And by the way, I absolutely love that - when viewing the stack, it's
> very useful to see what commits you still have to go etc. - stg series
> is concise yet fully descriptive.
Sure.
I mainly find myself using gitk origin.. for that now. My main problem
there is just that it's slow. (And File->Update) seems possibly even
slower than just killing and restarting it.--b.
^ permalink raw reply
* Re: Merging commits together into a super-commit
From: Carl Worth @ 2007-05-10 19:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: J. Bruce Fields, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20070510192106.GB4489@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:
> I think you are underestimating stg here.
Yes, maybe I didn't learn to use it well enough.
> You can stg init just once per branch (ever), I think.
I don't have details now, but I know I ran into some difficulty when
leaving the extra stg state around. It seems that it added stuff that
resulted in some reference of mine becoming ambiguous, ("refspec <foo>
matches more than one" perhaps?). What I do remember is that I couldn't
get one of my standard git push commands to work until I deleted all
of .git/refs/bases and .git/refs/patches and then things started to
work again.
> stg uncommit -n N
> stg pop -n N-1
> ..hack..
> stg refresh
> stg push -a
>
> It seems to be a bit shorter than the sequence you've presented above,
> and overally working with volatile commits using StGIT feels much more
> natural to me - and I haven't even ever used quilt seriously! (I have
> special antipathy to the git reset UI, too.)
The -n option is something I hadn't noticed, and that helps, (except
that what I've got to start with is a git revision name, not a
number).
But there are still some places where an experienced git user runs
into some awkward situations trying to use stg. For example, "stg
refresh" is basically always doing the equivalent of "commit -a" so
there's annoyingly no way to refresh only some of the modified state
into the commit.
Also, if I want to edit a commit message while under the influence of
stg, how do I do that? If I do "git commit --amend" will I seriously
confuse stg, (I'm guessing I would, but I don't know).
It's that kind of uncertainty that makes me uncomfortable to mix git
and stg. And personally, I couldn't get excited about using it alone,
(for example, in addition to the commit message with headline, stg
makes me invent yet _another_ name for every commit---yuck). Not to
mention I'm already quite comfortable with git alone, and all the
flexibility it provides.
Plus, all the stuff that stg provides to allow it to be used
standalone ends up just being noise to the git user that just wants to
do some stack-based manipulation of an unpublished branch, for
example.
So, I'd really like to see something more integrated into git itself
that provides some of the missing functionality.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Merging commits together into a super-commit
From: Petr Baudis @ 2007-05-10 19:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Carl Worth, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20070510192212.GP13719@fieldses.org>
On Thu, May 10, 2007 at 09:22:12PM CEST, J. Bruce Fields wrote:
> On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:
> > stg - This probably works great if you're using it as a primary
> > interface. But trying to use it as a quick one-off when
> > generally using core git does not work well at all. Instead of
> > the two "git tag" commands in my recipe above, an stg recipe
> > would involve a lot of additional bookkeeping with stg init, stg
> > uncommit [N times for fixing a commit N steps back in the
> > history], stg goto, stg push, etc.
>
> I also didn't like having to come up with another name for each
> patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.
Actually, you don't have to - if you don't specify the patch names,
stgit will make them up itself using the subject of the commit message
as a base.
And by the way, I absolutely love that - when viewing the stack, it's
very useful to see what commits you still have to go etc. - stg series
is concise yet fully descriptive. I'm pondering about whether something
like this couldn't be incorporated into other git UIs somehow as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Switching branch before commit
From: Ron Parker @ 2007-05-10 19:43 UTC (permalink / raw)
To: git
I know this is probably a FAQ and I thought I found it somewhere once,
but... How do I commit changes from in my working directory to another
(possibly non-existent) branch?
All too often I am working on changes and realize I am sitting on master
or a topic branch and I need to commit my mods to different branch. I
really don't like:
git commit
git branch <other-branch>
git reset --hard HEAD^
Is there anything like:
git commit -b <other-branch> [<file>...]?
If not, would patches to implement such a change be accepted?
^ permalink raw reply
* Re: [PATCHv2] connect: display connection progress
From: Junio C Hamano @ 2007-05-10 19:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Alex Riesen, git
In-Reply-To: <20070510120802.GG13655@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> Quoting Alex Riesen <raa.lkml@gmail.com>:
>> Subject: Re: [PATCHv2] connect: display connection progress
>>
>> On 5/10/07, Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:
>> >-static int git_tcp_connect_sock(char *host)
>> >+static int git_tcp_connect_sock(char *host, int flags)
>>
>> There is only one bit of flags ever used. What are the others for?
>
> Hmm, I thought it's easier to read
> git_tcp_connect_sock(host, NET_QUIET)
> than
> git_tcp_connect_sock(host, 1)
>
> but maybe that's overdesign.
>
>> Why use negative logic?
>> What was wrong with plain "int verbose"?
>
> I want the default to report connections, and -q
> to silence them. Maybe "int quiet"?
I would really feel this extra verbosity should not be the
default. Thanks.
^ 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