* [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
* 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
* 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: 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: [PATCH] show-branch: make --topo-order noop and default.
From: A Large Angry SCM @ 2006-01-13 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrsg41g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>Junio C Hamano wrote:
>>>It really does not make sense not doing --topo-order.
>>I disagree. I do like to see the chronological commit history of some
>>repositories.
>
> But the thing is if you do chronological order, you may not see
> enough commits without --more=, because show-branches stops at
> the first common commit. Try it yourself in a repository with
> merges on topic branches of different vintage, with and without
> the option, to see where output stops.
Interesting, I don't think I've ever looked far enough to triggered the
stop condition in my repositories of interest before.
How about making topo-order the default but having an option for
chronological order?
^ permalink raw reply
* Re: [PATCH] stgit: fix clone
From: Pavel Roskin @ 2006-01-13 5:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: cel, git
In-Reply-To: <b0943d9e0601120354u73489c74j@mail.gmail.com>
On Thu, 2006-01-12 at 11:54 +0000, Catalin Marinas wrote:
> See the attached patch for a different fix and let me know if there
> are any issues with it. I should probably release 0.8.1 with the fixed
> bugs.
I see you have applied the fix already. Current StGIT is working fine
when it comes to cloning. Thank you!
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 4:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmm0eod1.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jan 2006 20:35:54 -0800
Junio C Hamano <junkio@cox.net> wrote:
> You are obviously not talking about the use of "git commit" as a
> building block of some script (if you were, it would not make an
> iota of difference whether it is a command line option, an extra
> "echo From: $name" prepending that to the body of the message,
> or setting GIT_AUTHOR_* variables).
Correct. Although, even as a building block script this might
be a nice little touch; as you mentioned it might be able to
simplify the git-am script.
> So you must be talking about some manual process, at the end of
> which the user invokes "git commit" from the command line.
Yes, and in truth I only have a vague notion of his process.
> But I would imagine that "git commit" is preceded by a bigger
> process of preparing the tree to the committable state out of
> what is stored in the foreign SCM, after the user figures out
> which commit to pick from (in the original example; the
> committable state may come from something other than SCM ---
> e.g. set of tarballs or patch application or random monkey
> typing). And the whole process of "preparing the tree" and
> "committing" would be done number of times (otherwise we would
> not be having this discussion --- just use GIT_AUTHOR_* which is
> already available), so having to set them as separate steps
> between 'preparing the tree' and 'committing using "git commit"'
> is cumbersome.
Agreed, except even in the one-off case I think being able to set
the author info on the command line would be better. The GIT_AUTHOR_*
variables only really make sense for defaults, and even that is better
handled with .git/config nowadays.
>
> But you would write 'preparing the tree' (which may include
> "figuring out who the author is and what the log has to say" if
> the committable state is coming from a foreign SCM) script
> anyway, and I simply do not understand why inserting a couple of
> setting and exporting of GIT_AUTHOR_* variables at the very end
> of that script before calling "git commit" from it, to make it
> not just a 'preparing the tree' script but 'prepare the tree and
> commit' script is such a big deal for you.
Hmmm.. we've already agreed that if there is a script to prepare
the tree then this is a non-issue. We're only talking when
everything is done from the command line. In fact, i'm suggesting
that if you offer this on the command line (or From: line) that fewer
scripts would need to be hacked together by git users for some simple
cases.
> If the committable state does not come from foreign SCM, then
> 'preparing tree' stage may only be able to prepare a committable
> tree, and log and authorship information might need to be
> typed/pasted by the user. But then your script would just do
> "read author" or "${VISUAL-vi} .msgfile" before eventually
> calling 'GIT_AUTHOR_NAME="$author" git commit -F .msgfile' from
> there, so I do not think it is such a big deal either.
Yes, this is almost what I emailed to the gentleman in the first place,
but as you noted there is more than just one variable to set so you can't
do it that way.. you end up having to:
$ 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. If git handled a GIT_AUTHOR_COMBINED or some such
where you could give the name and email together in one variable which
would be parsed, then that suggestion would be slightly more palatable
but still seems more obtuse than either just accepting it on the command
line or via a From: line.
> I guess the disagreement is primarily coming from that you think
> "git commit" is always the uppermost UI layer, while I feel "git
> commit" is _one_ possible building block of bigger scripts, but
> the true building block is "git commit-tree".
>
Yes, I think you nailed it here. I do see git-commit as a end-user script
rather than just a building block.
Sean
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 4:35 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP067B249A8110916F036FB3AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> I think you're over estimating the downsides of allowing this to be
> set the same was as it is in the git-am case and underestimating the
> number of people who would find it useful, but I personally don't
> really care if you'd rather have it as a command line option.
You are obviously not talking about the use of "git commit" as a
building block of some script (if you were, it would not make an
iota of difference whether it is a command line option, an extra
"echo From: $name" prepending that to the body of the message,
or setting GIT_AUTHOR_* variables).
So you must be talking about some manual process, at the end of
which the user invokes "git commit" from the command line.
But I would imagine that "git commit" is preceded by a bigger
process of preparing the tree to the committable state out of
what is stored in the foreign SCM, after the user figures out
which commit to pick from (in the original example; the
committable state may come from something other than SCM ---
e.g. set of tarballs or patch application or random monkey
typing). And the whole process of "preparing the tree" and
"committing" would be done number of times (otherwise we would
not be having this discussion --- just use GIT_AUTHOR_* which is
already available), so having to set them as separate steps
between 'preparing the tree' and 'committing using "git commit"'
is cumbersome.
But you would write 'preparing the tree' (which may include
"figuring out who the author is and what the log has to say" if
the committable state is coming from a foreign SCM) script
anyway, and I simply do not understand why inserting a couple of
setting and exporting of GIT_AUTHOR_* variables at the very end
of that script before calling "git commit" from it, to make it
not just a 'preparing the tree' script but 'prepare the tree and
commit' script is such a big deal for you.
If the committable state does not come from foreign SCM, then
'preparing tree' stage may only be able to prepare a committable
tree, and log and authorship information might need to be
typed/pasted by the user. But then your script would just do
"read author" or "${VISUAL-vi} .msgfile" before eventually
calling 'GIT_AUTHOR_NAME="$author" git commit -F .msgfile' from
there, so I do not think it is such a big deal either.
I guess the disagreement is primarily coming from that you think
"git commit" is always the uppermost UI layer, while I feel "git
commit" is _one_ possible building block of bigger scripts, but
the true building block is "git commit-tree".
^ permalink raw reply
* Re: [PATCH] show-branch: make --topo-order noop and default.
From: Junio C Hamano @ 2006-01-13 4:11 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <43C70F69.7010103@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Junio C Hamano wrote:
>> It really does not make sense not doing --topo-order.
>
> I disagree. I do like to see the chronological commit history of some
> repositories.
But the thing is if you do chronological order, you may not see
enough commits without --more=, because show-branches stops at
the first common commit. Try it yourself in a repository with
merges on topic branches of different vintage, with and without
the option, to see where output stops.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 4:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q48hizr.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jan 2006 20:03:36 -0800
Junio C Hamano <junkio@cox.net> wrote:
> sean <seanlkml@sympatico.ca> writes:
>
> > ... Apparently he is more or less
> > hand munging mutliple cvs branches into a nice git package for
> > Linus to pull. He said that many of the patches don't apply as-is
> > and need some manual tweaking before committing.
>
> Then what is needed is an exporter from those cvs branches into
> git. Well, don't we have one already? If it does not work for
> dirty changes, wouldn't it be better to fix it so it is
> restartable, just like when rebase stops it lets you fix up and
> go on, without having you to write "From: " or GIT_AUTHOR_*
> yourself and just does the right thing?
>
Yes perhaps there is some streamlining of the cvs importer that could
be done. However, I got the impression from him that he was cherry
picking stuff out of multiple cvs branches so perhaps that's beyond
what the cvs importer was ever designed to handle.
Anyway, I think this is a more general problem than just the cvs
importing case; the current interface for setting author information
is brain damaged and a better method should be offered.
I think you're over estimating the downsides of allowing this to be
set the same was as it is in the git-am case and underestimating the
number of people who would find it useful, but I personally don't
really care if you'd rather have it as a command line option.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Junio C Hamano @ 2006-01-13 4:09 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C70D03.4040609@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> ISTR there was a thread that suggested using CVSROOT/users file
>> for this purpose.
>> http://thread.gmane.org/gmane.comp.version-control.git/8167
>
> ISTR?
I seem to recall...
> That patch doesn't work when importing from sourceforge...
>
> 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".
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 4:03 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP102ED7B30D2B48BEE601F5AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> ... Apparently he is more or less
> hand munging mutliple cvs branches into a nice git package for
> Linus to pull. He said that many of the patches don't apply as-is
> and need some manual tweaking before committing.
Then what is needed is an exporter from those cvs branches into
git. Well, don't we have one already? If it does not work for
dirty changes, wouldn't it be better to fix it so it is
restartable, just like when rebase stops it lets you fix up and
go on, without having you to write "From: " or GIT_AUTHOR_*
yourself and just does the right thing?
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek3chj8j.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jan 2006 19:58:20 -0800
Junio C Hamano <junkio@cox.net> wrote:
> sean <seanlkml@sympatico.ca> writes:
>
> > ... In fact, it would seem more
> > consistent to tell someone that a From: line will be handled properly
> > whether they use git-am or git-commit.
>
> Yuck.
>
> Somebody using am/applymbox is not writing that "From: " line
> himself. The person who writes that "From: " line writes that
> into his MUA when sending a patch --- that is "editing an
> email", so there is a consistency between that activity and use
> of word "From: ".
>
> The editor for commit message does not have anything to do with
> e-mail. What you are talking about is not consistency, but
> confusion.
>
I don't imagine that the person "editing" the commit message is
doing so in this case either, rather copy-n-pasting. If you're
really dead-set against this method, you should at least consider
adding it as a command line option, because having to set this
via environment variables is a much bigger Yuck.
Sean
^ permalink raw reply
* Re: merging initial part of a branch?
From: Junio C Hamano @ 2006-01-13 4:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060113030837.GD27214@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> That's the only reference I can find to the "tag <tag>" notation, and
> it's a bit unhelpful as written. (What backward compatibility?)
>
> How about the following?--b.
Makes sense. Thanks.
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.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 3:58 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP1298D73139F4BE57D59B97AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> ... In fact, it would seem more
> consistent to tell someone that a From: line will be handled properly
> whether they use git-am or git-commit.
Yuck.
Somebody using am/applymbox is not writing that "From: " line
himself. The person who writes that "From: " line writes that
into his MUA when sending a patch --- that is "editing an
email", so there is a consistency between that activity and use
of word "From: ".
The editor for commit message does not have anything to do with
e-mail. What you are talking about is not consistency, but
confusion.
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Alexander Litvinov @ 2006-01-13 3:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vvewohoy0.fsf@assigned-by-dhcp.cox.net>
On Friday 13 January 2006 07:55, Junio C Hamano wrote:
> ISTR there was a thread that suggested using CVSROOT/users file
> for this purpose.
>
> http://thread.gmane.org/gmane.comp.version-control.git/8167
This should went into docs for cvsimport. Before now I knew there is a way to
import authors but I did not find anything in cvsimport script. This patch
shows not only me lost this feature.
^ permalink raw reply
* Re: merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-13 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzi2i5eu.fsf@assigned-by-dhcp.cox.net>
On Wed, Jan 11, 2006 at 05:47:05PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> >> I haven't tried this for some time, but I presume
> >>
> >> $ git pull linus tag v2.6.15
> >>
> >> would do what you want.
> >
> > Yep! Thanks. The only documentation I can find for this is a slightly
> > obscure bit in the git-pull man page which lists this as a "short-cut"
> > notation. What is it a shortcut for? Is it possible to specify an
> > arbitrary commit in place of the "tag v2.6.15" somehow?
>
> The phrase "short-hand" refers to "linus" in the above example.
> I.e. the name of the file in $GIT_DIR/remotes that records the
> URL (among other things).
No, I'm referring to the following language:
"Some short-cut notations are also supported.
"For backward compatibility, tag is almost ignored; it just
makes the following parameter <tag> to mean a refspec
refs/tags/<tag>:refs/tags/<tag>."
That's the only reference I can find to the "tag <tag>" notation, and
it's a bit unhelpful as written. (What backward compatibility?)
How about the following?--b.
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index b5b9792..4524fee 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -134,9 +134,9 @@ is often useful.
+
Some short-cut notations are also supported.
+
-* For backward compatibility, `tag` is almost ignored;
- it just makes the following parameter <tag> to mean a
- refspec `refs/tags/<tag>:refs/tags/<tag>`.
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
+ used with pull or fetch, it requests fetching everything up to
+ the given tag.
* A parameter <ref> without a colon is equivalent to
<ref>: when pulling/fetching, and <ref>`:`<ref> when
pushing. That is, do not store it locally if
^ permalink raw reply related
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 2:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060112201646.GA3179@steel.home>
On Thu, 12 Jan 2006 21:16:46 +0100
Alex Riesen <raa.lkml@gmail.com> wrote:
> > Use the author name and email information given as the
> > first line of the commit message in the form of:
> >
> > From: name <email>
> >
> Isn't this what git-am expect (as a part of mbox) and handle?
>
Hi Alex,
Yes it is, but not everyone is processing patches in mbox format. If
this facility is good enough for the mbox users, it seems like it would
be good enough for non-mbox users. In fact, it would seem more
consistent to tell someone that a From: line will be handled properly
whether they use git-am or git-commit.
Sean
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 2:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: junkio, git
In-Reply-To: <43C6CFC5.5010902@op5.se>
On Thu, 12 Jan 2006 22:53:09 +0100
Andreas Ericsson <ae@op5.se> wrote:
> Junio C Hamano wrote:
> >
> > If you typed that line, why somebody else's change ended up in
> > your working tree is a mystery to me, but let's say an
> > office-mate edited things for you and said "this should work.
> > test it out and if it is OK commit it for me." I have seen this
> > kind of thing done in real life.
> >
> This happens from time to time where I work, but I think it would be
> more useful to have
>
> --from="Some User <some.user@theoffice.org>"
>
> which would save even more typing.
>
> I had thought of coupling this with some translation-scheme thingie, so
> that "--from=jd" would be automagically converted to the proper name and
> email address. I first came to think about this when I imported most of
> our projects from CVS, but I ended up doing a quick-hack to
> git-cvsimport instead.
Yeah, this might be the way to go; however if you are cutting and pasting
the commit message already, this might be slightly less convenient because
now you have to copy-n-paste to the command line instead of just to your
commit editor. Hopefully it would help to avoid the need for others
to hack the scripts ;o) Also it would be nice if it could help simplify
the git-am script as Junio suggested too.
Sean
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-13 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jan 2006 12:13:52 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Actually, I've considered this a couple of times in the past,
> but I ended up saying no.
>
> If the workflow is driving "git commit" from a script (i.e. your
> own Porcelain), the script can set GIT_AUTHOR_* environment
> variables, so this is a non issue.
Yes, obviously if there is another wrapper this isn't needed because
that script could parse the From: line out of the text as well.
> Which means that this 'From: ' thing is coming from the end
> user. Either you as the end user pasted it from some text file,
> or typed that line because you knew that the change was made by
> that person, not by you.
>
> If you pasted that line from somewhere else, I wonder what that
> "somewhere else" file is -- and what else that file contained.
> If the change came in an e-mail message, we already have tools
> for that (am/applymbox), and they do not lose the author-date
> information as your change to git-commit does, so I think it is
> a non issue.
This idea came up because recently on tLKML there was someone who
asked Linus to pull from him that had all the author names as his
own and a From: line in a bunch of the commit messages.
When I sent him an email asking why he explained that it was
just too cumbersome to bother setting up the proper author
using git environment variables. Apparently he is more or less
hand munging mutliple cvs branches into a nice git package for
Linus to pull. He said that many of the patches don't apply as-is
and need some manual tweaking before committing.
> And I do not think of anything else that would have author name
> but does not have a patch text that you can feed git-apply with.
> Pasting from your address book just to save typing does not
> count as "pasting" --- that is still typing in this context.
>
> If you typed that line, why somebody else's change ended up in
> your working tree is a mystery to me, but let's say an
> office-mate edited things for you and said "this should work.
> test it out and if it is OK commit it for me." I have seen this
> kind of thing done in real life.
>
> If that is what happened, then what you are adding is a more
> convenient way than setting two GIT_AUTHOR_* environment
> variables. Maybe you forgot about preserving author date, in
> which case you would add 'Date: ' as well to your patch, and
> that would save your user from setting three environment
> variables.
Naw, I just don't think the date is as important or generally
cared about as much, but you're right maybe that'd help someone
too.
> So the matter really is how much this patch is better than
> setting GIT_AUTHOR_* environment variables, unless it simplifies
> things for other programs (one possibility I have not looked
> into is that we _might_ be able to use "git commit" with this
> modification from "git am/applimbox/revert/cherry-pick").
>
Yeah, i wondered about that too.
I think something like this patch, or as someone else suggested
one that accepts the author on the command line, is needed.
Having to set environment variables for this information just
doesn't make much sense if you ever need to change it in a manual
way, which is bound to happen from time to time.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] show-branch: make --topo-order noop and default.
From: A Large Angry SCM @ 2006-01-13 2:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q4ajonx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It really does not make sense not doing --topo-order.
>
I disagree. I do like to see the chronological commit history of some
repositories.
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Andreas Ericsson @ 2006-01-13 2:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vvewohoy0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> ISTR there was a thread that suggested using CVSROOT/users file
> for this purpose.
>
> http://thread.gmane.org/gmane.comp.version-control.git/8167
>
ISTR?
That patch doesn't work when importing from sourceforge (among others),
because no-one uses their devname@users.sourceforge.net address (and
often just filter them out because they attract so much spam). It also
does nothing for when the username isn't the leading part of the
email-addres, or for GIT_AUTHOR_NAME, which is the most disturbing since
it ruffles the shortlog output. We use that shortlog to get a gisted
changelog for the sales and marketing people. I can recommend this.
They're absolutely thrilled to see things like "Only use vararg macros
#ifdef __GNUC__" and "declare **envp const throughout mplex api". ;)
Anyways, I can keep this separate if you don't want to accept it. I'll
most likely implement some config-reading to it too though so I don't
have to type the repository name and such each time I run it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] checkout: merge local modifications while switching branches.
From: Junio C Hamano @ 2006-01-13 1:55 UTC (permalink / raw)
To: git
* Instead of going interactive, introduce a command line switch
'-m' to allow merging changes when normal two-way merge by
read-tree prevents branch switching.
* Leave the unmerged stages intact if automerge fails, but
reset index entries of cleanly merged paths to that of the
new branch, so that "git diff" (not "git diff HEAD") would
show the local modifications.
* Swap the order of trees in read-tree three-way merge used in
the fallback, so that `git diff` to show the conflicts become
more natural.
* Describe the new option and give more examples in the documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This comes on top of my yesterday's patch. I am trying this
out today in my day-job by deliberately developing on the
"test" branch (which is a merge of all the topic branches),
and then doing "checkout -m" to switch back to the relevant
topic branch. Things seem to work nicely.
Documentation/git-checkout.txt | 76 ++++++++++++++++++++++++++++++++++++----
git-checkout.sh | 60 ++++++++++++++++++++------------
2 files changed, 107 insertions(+), 29 deletions(-)
19394e9d4e99a1e49a5b958db66228df07dc8afb
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 9442c66..df9a618 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -7,7 +7,7 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
-'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
+'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]
DESCRIPTION
-----------
@@ -34,6 +34,19 @@ OPTIONS
-b::
Create a new branch and start it at <branch>.
+-m::
+ If you have local modifications to a file that is
+ different between the current branch and the branch you
+ are switching to, the command refuses to switch
+ branches, to preserve your modifications in context.
+ With this option, a three-way merge between the current
+ branch, your working tree contents, and the new branch
+ is done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git update-index`.
+
<new_branch>::
Name for the new branch.
@@ -42,13 +55,13 @@ OPTIONS
commit. Defaults to HEAD.
-EXAMPLE
--------
+EXAMPLES
+--------
-The following sequence checks out the `master` branch, reverts
+. The following sequence checks out the `master` branch, reverts
the `Makefile` to two revisions back, deletes hello.c by
mistake, and gets it back from the index.
-
++
------------
$ git checkout master <1>
$ git checkout master~2 Makefile <2>
@@ -59,15 +72,64 @@ $ git checkout hello.c <3>
<2> take out a file out of other commit
<3> or "git checkout -- hello.c", as in the next example.
------------
-
++
If you have an unfortunate branch that is named `hello.c`, the
last step above would be confused as an instruction to switch to
that branch. You should instead write:
-
++
------------
$ git checkout -- hello.c
------------
+. After working in a wrong branch, switching to the correct
+branch you would want to is done with:
++
+------------
+$ git checkout mytopic
+------------
++
+However, your "wrong" branch and correct "mytopic" branch may
+differ in files that you have locally modified, in which case,
+the above checkout would fail like this:
++
+------------
+$ git checkout mytopic
+fatal: Entry 'frotz' not uptodate. Cannot merge.
+------------
++
+You can give the `-m` flag to the command, which would try a
+three-way merge:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+------------
++
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+. When a merge conflict happens during switching branches with
+the `-m` option, you would see something like this:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+merge: warning: conflicts during merge
+ERROR: Merge conflict in frotz
+fatal: merge program failed
+------------
++
+At this point, `git diff` shows the changes cleanly merged as in
+the previous example, as well as the changes in the conflicted
+files. Edit and resolve the conflict and mark it resolved with
+`git update-index` as usual:
++
+------------
+$ edit frotz
+$ git update-index frotz
+------------
+
Author
------
diff --git a/git-checkout.sh b/git-checkout.sh
index 76e6a41..bd7f007 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[-f] [-b <new_branch>] [<branch>] [<paths>...]'
+USAGE='[-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
SUBDIRECTORY_OK=Sometimes
. git-sh-setup
@@ -9,6 +9,7 @@ new=
force=
branch=
newbranch=
+merge=
while [ "$#" != "0" ]; do
arg="$1"
shift
@@ -26,6 +27,9 @@ while [ "$#" != "0" ]; do
"-f")
force=1
;;
+ -m)
+ merge=1
+ ;;
--)
break
;;
@@ -71,7 +75,7 @@ done
if test "$#" -ge 1
then
- if test '' != "$newbranch$force"
+ if test '' != "$newbranch$force$merge"
then
die "updating paths and switching branches or forcing are incompatible."
fi
@@ -121,32 +125,44 @@ then
git-checkout-index -q -f -u -a
else
git-update-index --refresh >/dev/null
- git-read-tree -m -u $old $new || (
- echo >&2 -n "Try automerge [y/N]? "
- read yesno
- case "$yesno" in [yY]*) ;; *) exit 1 ;; esac
-
- # NEEDSWORK: We may want to reset the index from the $new for
- # these paths after the automerge happens, but it is not done
- # yet. Probably we need to leave unmerged ones alone, and
- # yank the object name & mode from $new for cleanly merged
- # paths and stuff them in the index.
-
- names=`git diff-files --name-only`
- case "$names" in
- '') ;;
- *)
- echo "$names" | git update-index --remove --stdin ;;
+ merge_error=$(git-read-tree -m -u $old $new 2>&1) || (
+ case "$merge" in
+ '')
+ echo >&2 "$merge_error"
+ exit 1 ;;
esac
+ # Match the index to the working tree, and do a three-way.
+ git diff-files --name-only | git update-index --remove --stdin &&
work=`git write-tree` &&
- git read-tree -m -u $old $work $new || exit
+ git read-tree --reset $new &&
+ git checkout-index -f -u -q -a &&
+ git read-tree -m -u $old $new $work || exit
+
if result=`git write-tree 2>/dev/null`
then
- echo >&2 "Trivially automerged." ;# can this even happen?
- exit 0
+ echo >&2 "Trivially automerged."
+ else
+ git merge-index -o git-merge-one-file -a
fi
- git merge-index -o git-merge-one-file -a
+
+ # Do not register the cleanly merged paths in the index yet.
+ # this is not a real merge before committing, but just carrying
+ # the working tree changes along.
+ unmerged=`git ls-files -u`
+ git read-tree --reset $new
+ case "$unmerged" in
+ '') ;;
+ *)
+ (
+ z40=0000000000000000000000000000000000000000
+ echo "$unmerged" |
+ sed -e 's/^[0-7]* [0-9a-f]* /'"0 $z40 /"
+ echo "$unmerged"
+ ) | git update-index --index-info
+ ;;
+ esac
+ exit 0
)
fi
--
1.1.1-gae96
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Junio C Hamano @ 2006-01-13 1:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20060112233859.3438F5BED0@nox.op5.se>
ISTR there was a thread that suggested using CVSROOT/users file
for this purpose.
http://thread.gmane.org/gmane.comp.version-control.git/8167
^ permalink raw reply
* [PATCH] git-push: avoid falling back on pushing "matching" refs.
From: Junio C Hamano @ 2006-01-13 1:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601121006040.3535@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Having to list all tags/branches is slightly painful. I currently push out
> all my tags with
>
> ./push-all $(cd .git/refs ; find -type f tags)
>
> which works but isn't exactly user-friendly ("push-all" is just a script
> that uses "git push" to push to multiple repositories).
So here it is, to add --tags and avoid falling back to
"matching" default.
-- >8 --
The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote have, and "git push"
blindly inherits this property. Which probably was a mistake.
A typical cloned repository (e.g. a subsystem repository cloned
from Linus repository) has at least two branches, "master" to
keep the subsystem and "origin" that records tip of Linus
"master" when the repository was cloned. If this is the public
repository for the subsystem, then subsystem developers would
clone it, and then cloned ones have "master" and "origin". When
developers use this public subsystem repository as a shared
repository, pushing into it via "git push subsys:/path/name"
would try to push the matching refs, "master" and "origin", from
the developers' repositories. The "origin" in the public shared
repository does not have much relevance, yet pushing into
"origin" would cause "not a fast forward" checks to be
triggered. Arguably "git push subsys:/path/name master" would
work it around, but having them to say it explicitly to avoid
pushing into "origin" as well is bad.
This commit requires you to give at least one refspec to
git-push. You could "give" by either:
(1) Listing the refspec(s) explicitly on the command line.
E.g. "git push subsys:/path/name master".
(2) Using --all or --tags on the command line.
E.g. "git push --tags subsys:/path/name".
(3) Using a $GIT_DIR/remotes shorthand with 'Push: refspec'
line in it.
Unlike pull that can happen pretty much promiscuously, people
will push into the same set of a limited number of remote
repositories repeatedly over the life of the project, so it is
reasonable to assume they would want to keep a $GIT_DIR/remotes/
entry for those repositories even only to save typing the URL,
so keeping the default 'Push: refspec' line in such is a
sensible thing to do.
It was suggested to further fall back on pushing the current
branch, but this commit does not implement it. If developers
adopt topic branch workflow, pushing to public while on a topic
branch by mistake would expose the topic branch to the public
repository. Not falling back to the current branch prevents
that mistake from happening.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-push.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
85393139981c28a2df93950b00e4712dc4bca56c
diff --git a/git-push.sh b/git-push.sh
index 1c5cf80..2b97e09 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -9,12 +9,15 @@ has_all=
has_force=
has_exec=
remote=
+do_tags=
while case "$#" in 0) break ;; esac
do
case "$1" in
--all)
has_all=--all ;;
+ --tags)
+ do_tags=yes ;;
--force)
has_force=--force ;;
--exec=*)
@@ -33,6 +36,10 @@ case "$#" in
echo "Where would you want to push today?"
usage ;;
esac
+if test ",$has_all,$do_tags," = ",--all,yes,"
+then
+ do_tags=
+fi
. git-parse-remote
remote=$(get_remote_url "$@")
@@ -42,6 +49,20 @@ case "$has_all" in
esac
shift
+case "$do_tags" in
+yes)
+ set "$@" $(cd "$GIT_DIR/refs" && find tags -type f -print) ;;
+esac
+
+# Now we have explicit refs from the command line or from remotes/
+# shorthand, or --tags. Falling back on the current branch if we still
+# do not have any may be an alternative, but prevent mistakes for now.
+
+case "$#,$has_all" in
+0,)
+ die "No refs given to be pushed." ;;
+esac
+
case "$remote" in
git://*)
die "Cannot use READ-ONLY transport to push to $remote" ;;
--
1.1.1-g6009
^ permalink raw reply related
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