* Re: git-commit: allow From: line to be entered in commit message
From: Joel Becker @ 2006-01-13 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd89mc0y.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 12:22:53PM -0800, Junio C Hamano wrote:
> Committing somebody else's changes by hand ought to be a rare
> event. Otherwise that is an indication that there needs to be a
>...
> Most of the time when I use "git commit", I'll be committing my
> own changes; I do not want to see "From: me" every time I
> commit.
Well, I'm wary of putting
GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
environment, for fear of overriding some other authors at some point.
On the other hand, if I don't put it in the environment, I get a bogus
author line (jlbec@thisbox.oracle.com). So I end up having to
hand-write the AUTHOR_EMAIL lines on each commit line; not a solution
I'm happy with.
This way, I'd have a chance to edit it and be sure :-)
Joel
--
Life's Little Instruction Book #274
"Leave everything a little better than you found it."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 7:06 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20060113065855.GJ14196@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> Well, I'm wary of putting
> GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> environment, for fear of overriding some other authors at some point.
The weakest default comes from .git/config so you could have
this in your .git/config:
[user]
name = Joel Becker
email = Joel.Becker@oracle.com
and you can have GIT_AUTHOR_* override it as necessary.
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Junio C Hamano @ 2006-01-13 8:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <7vzmm0g45a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Anyways, I can keep this separate if you don't want to accept it.
>
> Oh, I haven't formed an opinion on accept/reject yet. I was
> just trying to see if you are aware of that (especially Pasky's
> message in that thread) and thought about issues like "if in
> some repositories CVSROOT/users is in usable form then perhaps
> making sure -A file has the same format and suggest its use in
> the documentation would be nicer".
OK, after a little googling around, I have formed an opinion. I
agree to the patch in principle, but at least it would be nicer
to use "CVSROOT/users" compatible format before giving it to the
general public.
http://computing.ee.ethz.ch/sepp/cvs-1.10-to/cvsbook/main_70.html
seems to indicate that:
- colon ':' is used instead of your '='.
- RHS, if it contains a whitespace, is quoted either with
single or double quote.
It was a bit unclear to me how quote characters are to be
quoted, so the patch needs a bit of research, quoting (when
writing out new records) and unquoting (when reading) in the
script, but otherwise I think it is a welcome change.
Opinions from other heavy CVS users?
^ permalink raw reply
* [PATCH] stgit: make tutorial a valid asciidoc article
From: Pavel Roskin @ 2006-01-13 8:54 UTC (permalink / raw)
To: Catalin Marinas, git
There should be only one level 0 title in an article, so lower ranks of
all headers by one. Make capitalization uniform in the headers - level
1 is capitalized, but level 2 is not. Create a new level 1 part
"Technical Information".
Make ".git/ Directory Structure" a level 2 header and rephrase.
asciidoc doesn't like headers starting with a dot.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
doc/tutorial.txt | 34 +++++++++++++++++++---------------
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 7183e41..eae26f4 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -16,10 +16,10 @@ information on GIT, see the GIT_tutorial
Basic Operation
-===============
+---------------
Help
-----
+~~~~
For a full list of StGIT commands:
@@ -31,7 +31,7 @@ For help on individual subcommands:
Repository initialisation
--------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~
In stand-alone mode, StGIT is used in conjunction with a GIT repository
that is already initialised (using 'git-init-db'). StGIT cannot be used
@@ -59,7 +59,7 @@ will automatically prepare them for use
Working with remote repositories
---------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With a single command, StGIT can create and initialize a GIT repository
which mirrors a remote GIT repository. This is known as cloning. All GIT
@@ -97,7 +97,7 @@ separated into its own branch to make it
just your patches.
Getting started: creating a patch
----------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changes to your working directory are saved in a patch. An StGIT patch
is simply a saved set of modifications to your working directory, plus a
@@ -140,7 +140,7 @@ commands:
Stack manipulation: managing multiple patches
----------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
StGIT can manage more than one patch at a time. A series of StGIT
patches in a GIT branch are known collectively as a stack. The new patch
@@ -200,7 +200,7 @@ you want to permanently store the applie
them with StGIT.
Converting between StGIT patches and text diffs
------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As mentioned in the introduction, StGIT stores modifications to your
working tree in the form of GIT commits. This means if you want to apply
@@ -270,10 +270,10 @@ the bottom of the topmost one and perfor
Advanced Usage
-==============
+--------------
Handling merge conflicts
-------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~
Pushing a patch on the stack can fail if the patch cannot be applied
cleanly. This usually happens if there are overlapping changes in the
@@ -293,7 +293,7 @@ resolve the conflict.
Configuration file
-------------------
+~~~~~~~~~~~~~~~~~~
StGIT tries to read the configuration options from the following files:
/etc/stgitrc, ~/.stgitrc and .git/stgitrc. The latter overrides the
@@ -307,7 +307,7 @@ specify a smarter tool to be used.
Templates
----------
+~~~~~~~~~
The 'export' and 'mail' commands use templates for generating the patch
files or e-mails. The default templates are installed under <prefix>/
@@ -324,7 +324,7 @@ lines.
Merging two patches into one
-----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no command to do this directly at the moment but one can export
the patch to be merged and use the 'stg fold' command on the generated
@@ -334,8 +334,11 @@ result in an empty patch (StGIT notifyin
deleted.
-A Bit of StGIT Patch Theory
-===========================
+Technical Information
+---------------------
+
+A bit of StGIT patch theory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
We assume that a patch is a diff between two nodes - bottom and top. A
node is a commit SHA1 id or tree SHA1 id in the GIT terminology:
@@ -374,8 +377,9 @@ The above operation allows easy patch re
Removing (popping) a patch from the stack is done by simply setting the
Nst to Nb.
-.git/ Directory Structure
+Layout of the .git directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HEAD -> refs/heads/<something>
objects/
--
Regards,
Pavel Roskin
^ permalink raw reply related
* StGIT: "stg new" vs "stg new --force"
From: Pavel Roskin @ 2006-01-13 9:24 UTC (permalink / raw)
To: Catalin Marinas, git
Hello, Catalin!
Maybe I don't understand something in StGIT, but it seems strange that
"stg new" creates empty patch by default and requires "--force" to
create a non-empty patch.
It's much easier to give a patch a name once I know what it does. Most
times I don't even intend to make a patch. Suppose, I compile
something, then I find that some quick hack is needed to compile, then
the hack becomes a reasonable general solution. When does it make sense
to run "stg new"? Obviously, at the point when I know the patch is good
enough to be kept and sent upstream. It happens after I change some
files, not before.
It's actually very rare that I decide to fix something like "bug #42
from the tracker" before having changed a single line. It's also rare
that I follow through without getting distracted or realizing that I'm
fixing some other bug instead.
Also, "--force" is a strong word for a switch. It's normally used for
options that could trigger information loss or unintended consequences
that are hard to undo. Telling StGIT to record my changes hardly
qualifies as anything dangerous.
I know of "stg rename", but I don't want to be forced to name a patch
before it's ready.
Possible solutions:
1) "stg new --force" becomes "stg new" and "stg new" becomes "stg new
--empty", i.e. empty files can only be created with the "--empty"
switch.
2) "stg new --force" becomes "stg record" or something.
3) "stg new --force" becomes "stg new --record" or something.
4) "stg new" works both with and without modified files.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Karl Hasselström @ 2006-01-13 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <1137144291.20073.104.camel@dv>
On 2006-01-13 04:24:51 -0500, Pavel Roskin wrote:
> 1) "stg new --force" becomes "stg new" and "stg new" becomes "stg new
> --empty", i.e. empty files can only be created with the "--empty"
> switch.
> 2) "stg new --force" becomes "stg record" or something.
> 3) "stg new --force" becomes "stg new --record" or something.
> 4) "stg new" works both with and without modified files.
I agree with Pavel. I like option 4 the most, and 3 the least; since
creating a new patch from existing edits is more common (for me) than
creating an empty patch, it's awkward to make that command much
longer.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Artem Khodush @ 2006-01-13 11:11 UTC (permalink / raw)
To: git; +Cc: sean
In-Reply-To: <BAYC1-PASMTP01A07DAA61F181E9D9679EAE260@CEZ.ICE>
> $ export GIT_AUTHOR_NAME="$author"
> $ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
> Which is cumbersome and also ends up destroying your defaults if you happen
> to use that method, so afterward you have to unset them or reset them back
> to your own author info.
Hello,
I had a similar problem on cygwin. I agree that setting environment
variables by hand
is cumbersome, and modifying global environment is undesirable. I ended up with
writing shell script, named git-env.sh, that sets all variables
requred for git to work,
and got used to habit of typing
. git-env.sh
every time I intend to do some work in git.
When that environment is not needed any more,
I just close that particular shell window.
hope this helps,
Artem.
^ permalink raw reply
* Recursive remove
From: Peter Eriksen @ 2006-01-13 13:21 UTC (permalink / raw)
To: git
Hello,
A way to recursively remove a directory /Some/Dir/ is a follows:
git ls-files -z Some/Dir >rmfiles
git update-index -z --force-remove --stdin <rmfiles
git commit -a -m "Remove directory Some/Dir"
rm -rf Some/Dir
What is a better way to do it?
Regards,
Peter
^ permalink raw reply
* Re: Recursive remove
From: sean @ 2006-01-13 14:03 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060113132119.GB23655@ebar091.ebar.dtu.dk>
On Fri, 13 Jan 2006 14:21:19 +0100
"Peter Eriksen" <s022018@student.dtu.dk> wrote:
> Hello,
>
> A way to recursively remove a directory /Some/Dir/ is a follows:
>
> git ls-files -z Some/Dir >rmfiles
> git update-index -z --force-remove --stdin <rmfiles
> git commit -a -m "Remove directory Some/Dir"
> rm -rf Some/Dir
>
> What is a better way to do it?
>
Hi Peter,
The following is a bit more concise but not better than your version:
rm -rf Some/Dir
git ls-files -z -d Some/Dir | git-update-index -z --remove --stdin
git commit -m "Remove directory Some/Dir"
Git could stand to have an "rm" command to make this easier.
Sean
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Adrian Bunk @ 2006-01-13 14:50 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <20060112013706.GA3339@kroah.com>
On Wed, Jan 11, 2006 at 05:37:06PM -0800, Greg KH wrote:
> On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:
> >
> > I am using the workaround of carrying the patches in a mail folder,
> > applying them in a batch, and not pulling from your tree between
> > applying a batch of patches and you pulling from my tree.
>
> Ick, I'd strongly recommend using quilt for this. It works great for
> just this kind of workflow.
It works in my case because I'm only going through the folder with the
trivial patches in batches and ask Linus to pull from my tree
immediately after I'm finished.
That would certainly not be a recommended practice for a subsystem
maintainer, but I'm handling only trivial patches.
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* My first git success
From: walt @ 2006-01-13 14:51 UTC (permalink / raw)
To: git
All the help you guys have given me lately has at least
fixed one kernel bug :o)
After using git-bisect to find the responsible commit,
I emailed the maintainer who sent me back a patch to try.
I used git-checkout to make a new test branch, applied
and tested the patch (which fixed the bug) and I just
sent off an email to the maintainer to confirm.
And it was all so easy I never broke a sweat. Amazing!
So thank you all again for the help and your great work.
^ permalink raw reply
* Re: merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-13 15:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xtkhj5l.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 08:00:06PM -0800, Junio C Hamano wrote:
> Backward compatibility is that it was only either "<branch>" or
> "tag <tag>". When heads/branch or tags/tag came later,
> supporting the separate word form "tag <tag>" was a bit
> cumbersome but was done for b/c.
Thanks for the explanation, makes sense.
I might try to put together some more extensive documentation patches
over the next couple weeks if you're willing to take them. Plain git
actually seems to have pretty usable interfaces at this point, but it's
not always obvious where to find them....
I also have Yet Another Git Tutorial, at
http://www.fieldses.org/~bfields/kernel/git.html. (Corrections and
suggestions welcomed.)
--b.
^ permalink raw reply
* Re: My first git success
From: Linus Torvalds @ 2006-01-13 17:11 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq8epd$k28$1@sea.gmane.org>
On Fri, 13 Jan 2006, walt wrote:
>
> And it was all so easy I never broke a sweat. Amazing!
Heh. You're the "good tester" kind of person. Most people don't bother to
explain their problems well, and don't even bother to listen. And they
never call it "easy" if they had to get explanations.
I still hope the exchanges will result in more docs, or at least other
lurkers on the list also learning a new trick or two..
Linus
^ permalink raw reply
* Re: Recursive remove
From: Junio C Hamano @ 2006-01-13 17:37 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060113132119.GB23655@ebar091.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> A way to recursively remove a directory /Some/Dir/ is a follows:
>
> git ls-files -z Some/Dir >rmfiles
> git update-index -z --force-remove --stdin <rmfiles
> git commit -a -m "Remove directory Some/Dir"
> rm -rf Some/Dir
>
> What is a better way to do it?
$ rm -fr Some/Dir; git commit -a -m 'Remove'
perhaps?
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 17:40 UTC (permalink / raw)
To: Artem Khodush; +Cc: git, sean
In-Reply-To: <40b2b7d90601130311v78db741dx7c5eaa57ad300850@mail.gmail.com>
Artem Khodush <greenkaa@gmail.com> writes:
>> $ export GIT_AUTHOR_NAME="$author"
>> $ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
>
>> Which is cumbersome and also ends up destroying your defaults if you happen
>> to use that method, so afterward you have to unset them or reset them back
>> to your own author info.
>
> I had a similar problem on cygwin. I agree that setting environment
> variables by hand
> is cumbersome, and modifying global environment is undesirable...
Have you two known that more than one environment variables can
be set for one-shot command execution?
$ GIT_AUTHOR_NAME="$author" \
GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
would give these environment variables for this "git commit"
without affecting the later commands.
Not that this really matters, since the above example was an
excerpt of my suggestion about how to do this in a script,
somehow made to look as if it was a suggestion about running
things by hand from the command line...
^ permalink raw reply
* Re: qgit shows wrong popup
From: Marco Costalba @ 2006-01-13 17:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <e5bfff550601120455p1b1654cx43beb684a3fd5dc7@mail.gmail.com>
>>I found this comment in mainimpl.cpp:
>> // call an async context popup, DO NOT filter out event
>> // we append the event to main event loop queue so Qt can send
>> // currentChanged() signal to listViewLog before our popup is
>>populated
>>
>>I guess the code doesn't work the way the comment says.
>>
Hi Pavel,
please test the following an let me know if it is ok for you.
@@ -1378,9 +1378,21 @@ void MainImpl::customEvent(QCustomEvent*
if (e->type() == STATS_EV) // archive loading complete
loadComplete(((ThreadStatsEvent*)e)->data());
- if (e->type() == POPUP_EV) // deferred popup
- doContexPopup(listViewLog->currentItem());
-
+ if (e->type() == POPUP_EV) { // deferred popup
+ QListViewItem* item = listViewLog->currentItem();
+ if (item) {
+ // if mainview is already updated pop-up
+ // context menu, otherwise it means dispatch()
+ // has not been called til now, so resend the event,
+ // it will be queued up after dispatch.
+ if (item->text(COMMIT_COL) == mainViewSha)
+ doContexPopup(listViewLog->currentItem());
+ else {
+ DeferredPopupEvent* e = new DeferredPopupEvent();
+ QApplication::postEvent(this, e);
+ }
+ }
+ }
if (e->type() == POPUP_TREE_EV) // deferred tree popup
doTreeContexPopup(treeView->currentItem());
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 17:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: greenkaa, git
In-Reply-To: <7v64oo9gc7.fsf@assigned-by-dhcp.cox.net>
On Fri, 13 Jan 2006 09:40:24 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Have you two known that more than one environment variables can
> be set for one-shot command execution?
>
> $ GIT_AUTHOR_NAME="$author" \
> GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
>
> would give these environment variables for this "git commit"
> without affecting the later commands.
No, I didn't know that; thanks for the lesson.
>
> Not that this really matters, since the above example was an
> excerpt of my suggestion about how to do this in a script,
> somehow made to look as if it was a suggestion about running
> things by hand from the command line...
>
I said quite a few times now this has nothing to do with running
git-commit from a script. This is just a simple request
to not require the use of environment variables to pass useful
parameters.
I really don't understand your gripe on this one, when someone
else suggested using a command line parameter for author
information you said:
<quote>
> --from="Some User <some.user@theoffice.org>"
>
I agree this would be more useful, direct, easy to understand
and explain way to do it.
</quote>
So do you still agree with that, would you accept a patch? Or do you have
some fundamental reason to think that environment variables are a better
way to pass information in this case?
Cheers,
Sean
^ permalink raw reply
* Re: Recursive remove
From: sean @ 2006-01-13 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: s022018, git
In-Reply-To: <7virso9ggd.fsf@assigned-by-dhcp.cox.net>
On Fri, 13 Jan 2006 09:37:54 -0800
Junio C Hamano <junkio@cox.net> wrote:
>
> $ rm -fr Some/Dir; git commit -a -m 'Remove'
>
> perhaps?
>
Sigh, its been a humbling morning all around; can't get easier than that.
Sean
^ permalink raw reply
* Re: My first git success
From: Randal L. Schwartz @ 2006-01-13 18:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: walt, git
In-Reply-To: <Pine.LNX.4.64.0601130909290.3535@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> I still hope the exchanges will result in more docs, or at least other
Linus> lurkers on the list also learning a new trick or two..
I've also enjoyed a bit of success putting a website under git. I started
working on AJAX-ing some of the code, but I needed to do maintainence on the
live site, so I've just simply done "git-checkout master" to work on that, and
"git-checkout ajax; git-pull . master" when I want to continue work on the
ajax upgrades.
However, before I bug-fix, I have to "snapshot" any working changes in the
ajax branch or I would lose them on "git-checkout master", which gives me
commits that look like "snapshot". Am I doing that wrong? Is there a better
way to do parallel development of a "live vs upgrade" branch, and make commits
only when I make progress?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Joel Becker @ 2006-01-13 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsmwbo9s.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 11:06:07PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
>
> > Well, I'm wary of putting
> > GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> > environment, for fear of overriding some other authors at some point.
>
> The weakest default comes from .git/config so you could have
> this in your .git/config:
>
> [user]
> name = Joel Becker
> email = Joel.Becker@oracle.com
This configuration is something I have the opportunity to forget
every time I call git-clone. So I still need to leave it in the
environment permanently.
Am I correct in assuming that "From:" lines will override the
environment when using git-applymbox? If so, I guess leaving
GIT_AUTHOR_* in my environment permanently will be ok.
Joel
--
"War doesn't determine who's right; war determines who's left."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: My first git success
From: Peter Eriksen @ 2006-01-13 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <86y81kvtvj.fsf@blue.stonehenge.com>
On Fri, Jan 13, 2006 at 10:57:04AM -0800, Randal L. Schwartz wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>
> Linus> I still hope the exchanges will result in more docs, or at least other
> Linus> lurkers on the list also learning a new trick or two..
>
> I've also enjoyed a bit of success putting a website under git. I started
> working on AJAX-ing some of the code, but I needed to do maintainence on the
> live site, so I've just simply done "git-checkout master" to work on that, and
> "git-checkout ajax; git-pull . master" when I want to continue work on the
> ajax upgrades.
>
> However, before I bug-fix, I have to "snapshot" any working changes in the
> ajax branch or I would lose them on "git-checkout master", which gives me
> commits that look like "snapshot". Am I doing that wrong? Is there a better
> way to do parallel development of a "live vs upgrade" branch, and make commits
> only when I make progress?
I've been wondering this myself. Perhaps the following way would work?
git checkout ajax # Work on the ajax branch.
git diff HEAD >ajaxdiff
git checkout -f master # Work on the bug fix in master.
git commit -a -m "Bug fix in master"
git checkout ajax
git apply ajaxdiff
git commit -a -m "Finished commit in ajax"
This is untested, so it's only for inspiration.
Regards,
Peter
^ permalink raw reply
* Re: My first git success
From: Junio C Hamano @ 2006-01-13 19:37 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86y81kvtvj.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> However, before I bug-fix, I have to "snapshot" any working changes in the
> ajax branch or I would lose them on "git-checkout master", which gives me
> commits that look like "snapshot". Am I doing that wrong? Is there a better
> way to do parallel development of a "live vs upgrade" branch, and make commits
> only when I make progress?
Although I am sure others would suggest to use more than one
working tree, here are what I generally do, which does not
require more than one.
-- >8 --
Interrupted workflow
--------------------
When you are in the middle of a large change, you can get
interrupted. The files in your working tree is not in any shape
to be committed, but you need to get to the other branch for a
quick fix.
------------
: on ajax; work work work
: on ajax; git commit -a -m 'snapshot WIP' <1>
: on ajax; git checkout master
: on master; fix fix fix
: on master; git commit ;# commit with real log
: on master; git checkout ajax
: on ajax; git reset --soft HEAD^ ;# go back to WIP state <2>
<1> This commit will get blown away so short log message is just fine.
<2> This removes the 'WIP' commit from the commit history, and makes
your working tree in the state just before you made that snapshot.
------------
The only difference between the state immediately before <1> and
immediately after <2> is that files you committed in <1> are
still registered in index at state <2>, so your "git diff" would
not give you what you were in the middle of doing at point <2>
and you need to say "git diff HEAD" instead. You could do a
------------
: on ajax; git read-tree -m HEAD
------------
immediately after the soft reset, which sets your index file to
the last commit you were basing your ajax work on.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 19:39 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20060113191231.GM14196@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> Am I correct in assuming that "From:" lines will override the
> environment when using git-applymbox? If so, I guess leaving
> GIT_AUTHOR_* in my environment permanently will be ok.
That's what I do. Although I use git-am not git-applymbox, both
of them are designed to work that way.
^ permalink raw reply
* Re: merging initial part of a branch?
From: Junio C Hamano @ 2006-01-13 19:50 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060113151005.GA29804@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> .... Plain git
> actually seems to have pretty usable interfaces at this point, but it's
> not always obvious where to find them....
I share that feeling too, especially in the documentation area.
Last time we had something very nice going on in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/12917
whose the key article is:
http://article.gmane.org/gmane.comp.version-control.git/13360
but the general sentiment was that having another document is
making things more confusing and we should try to clarify the
main documentation instead. Pasky said aptly:
http://article.gmane.org/gmane.comp.version-control.git/13410
I am not much of a documentation person myself, and I do not
have much interaction with people new to git, without which it
is hard to know which point is harder to grasp and what
documentation pages assume certain things are known to an
uninitiated when they should not.
So I would really appreciate documentaiotn patches to clarify
the current mess ;-).
> I also have Yet Another Git Tutorial, at
> http://www.fieldses.org/~bfields/kernel/git.html. (Corrections and
> suggestions welcomed.)
The $prefix defaults to $HOME/bin/. Having $bindir on $PATH
ought to be enough and exporting GIT_EXEC_PATH is not needd.
Other than that I did not see anything obviously wrong, although
I suspect you did not intend to say clone with stgit.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 19:51 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0918AE856AD34E35597CA4AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> So do you still agree with that, would you accept a patch? Or do you have
> some fundamental reason to think that environment variables are a better
> way to pass information in this case?
Fundamental reason of not doing anything is (1) not to make
unnecessary changes and (1) to avoidi decisions ;-).
No objections to --from='John Doe <john.doe@example.com>' by
itself, other than "You could say GIT_AUTHOR_* before the
command instead of --from after the command; as long as it is
not done regularly as an interactive command, the difference
does not matter". At that point, "making no unneeded changes"
kicks in. While I do understand that it might be necessary to
commit somebody else's patch occasionally, you have not
convinced me that is not such a rare thing, so until then the
change stays at lower priority.
After I am convinced that it is not so rare and having an easier
and more consistent way (something coming from environment and
other things from command line is inconsistent) would generally
be a good addition, I further need to think about these issues
before taking such a patch, in the context of the "git commit"
command as a whole:
- Is --from the right word? Shouldn't it be --author?
- Do we want author date? If not, why not?
- What about committer information? If not, why not?
^ 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