* Re: git refuses to work with gvim
From: Felipe Contreras @ 2009-10-12 14:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <20091012142523.GH9261@spearce.org>
On Mon, Oct 12, 2009 at 5:25 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> >
>> > Someone needs to whack gvim upside the head and fix that program
>> > to behave correctly.
>>
>> Huh? What is wrong about 'gvim --nofork'?
>
> The fact that its a command line option that isn't the default.
> gvim's UI here is as bad as pre 0.99 git.
>
> People do:
>
> export EDITOR=gvim
>
> and things work OK for a while, as they always open a new editor,
> work with the file, and then close it, killing the only running gvim
> session. Since gvim waits if its the only gvim process running,
> things seem fine. But days later when you leave a file open,
> suddenly the command calling $EDITOR starts failing.
I've never seen it happening. For me either it aways fails (fork) or
always work (nofork).
> I've seen it happen to a lot of people. They just start complaining
> about how one day "git commit" is fine, and the next day its
> not working. But its been weeks since they selected gvim as their
> $EDITOR and they can't connect the open editor window as the problem
> with that Goddamn Idiotic Truckload of s**t they are forced to use.
Yeah, it happened to me too, but eventually I realized what was
happening. I like gvim's default behavior tough.
I personally don't see any problem... how about other SCMs?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Shawn O. Pearce @ 2009-10-12 14:34 UTC (permalink / raw)
To: Vietor Liu; +Cc: Johannes Schindelin, git
In-Reply-To: <1255335812.2326.20.camel@localhost.localdomain>
Vietor Liu <vietor@vxwo.org> wrote:
> On Mon, 2009-10-12 at 09:35 +0200, Johannes Schindelin wrote:
> >
> > So what you _actually_ do is reduce the space for the diff, no?
Dscho, I think what's happening is he is shrinking the minimum height
of the diff pane. By allowing it to be shorter he is trading diff
pane space in order to make room for the fixed height commit message
area below it.
> Yes.
> The _main window_ support auto resize. I was tested some way, only
> modify _diff body_ space could work. The _diff body_ is part of _main
> window_.
>
> Whether modify the commit message?
Yes, please modify the commit message. The message does not clearly
state what is occurring here, which is why Dsco had an issue.
Really you are trying to adjust the minimum height of the diff
pane, which is resizable, so that it can use less vertical height,
allowing the overall window to be shorter and still display the
entire commit pane.
Also, I find your use of underscores around widget names to be
very difficult to read. I don't see a reason for it in the commit
message.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 14:30 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120725u72cdb588p3c66bc730e6953d@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> That's OK, but I want to backup my git repo locally
Just change the path of the backup remote (that final argument to
git remote add) to point to the local directory.
Though I guess you would also need to run git init there, e.g.:
git --git-dir=/backup/project.git init
git remote add --mirror backup /backup/project.git
# and create the hook as below
Of course, backup to another folder on the same disk isn't a backup
at all, the disk can still fail and lose both repositories.
> On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Israel Garcia <igalvarez@gmail.com> wrote:
> >> Which is the simplest way to backup a git repository after every commit?
> >
> > Add a commit hook to push to another location, e.g.:
> >
> > git remote add --mirror backup you@another.host:path/to/backup.git
> >
> > cat >.git/hooks/post-commit
> > #!/bin/sh
> > git push backup
> > ^D
> >
> > chmod a+x .git/hooks/post-commit
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: complete refs for git-grep
From: Shawn O. Pearce @ 2009-10-12 14:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <9f58ba1e7db9702d1b0594a8016c204e3d50b72f.1255337776.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> > So I'll roll a simpler patch that just always (before --) completes
> > refs instead, if that's ok.
Hard to argue with that logic. :-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 6fd7e1d..b08cd77 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1048,7 +1048,8 @@ _git_grep ()
> return
> ;;
> esac
> - COMPREPLY=()
> +
> + __gitcomp "$(__git_refs)"
> }
--
Shawn.
^ permalink raw reply
* Re: git refuses to work with gvim
From: Shawn O. Pearce @ 2009-10-12 14:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <94a0d4530910120720pccaa920n7ab407494473ac7b@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Someone needs to whack gvim upside the head and fix that program
> > to behave correctly.
>
> Huh? What is wrong about 'gvim --nofork'?
The fact that its a command line option that isn't the default.
gvim's UI here is as bad as pre 0.99 git.
People do:
export EDITOR=gvim
and things work OK for a while, as they always open a new editor,
work with the file, and then close it, killing the only running gvim
session. Since gvim waits if its the only gvim process running,
things seem fine. But days later when you leave a file open,
suddenly the command calling $EDITOR starts failing.
I've seen it happen to a lot of people. They just start complaining
about how one day "git commit" is fine, and the next day its
not working. But its been weeks since they selected gvim as their
$EDITOR and they can't connect the open editor window as the problem
with that Goddamn Idiotic Truckload of s**t they are forced to use.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Israel Garcia @ 2009-10-12 14:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091012141544.GF9261@spearce.org>
Hi Shawn,
That's OK, but I want to backup my git repo locally because I don't
have another remote git server. Can you modify your post-commit code
to backup the repo to /backups/git folder instead of using another
external git repo?
thanks in advance.
regards
Israel.
On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> Which is the simplest way to backup a git repository after every commit?
>
> Add a commit hook to push to another location, e.g.:
>
> git remote add --mirror backup you@another.host:path/to/backup.git
>
> cat >.git/hooks/post-commit
> #!/bin/sh
> git push backup
> ^D
>
> chmod a+x .git/hooks/post-commit
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: git refuses to work with gvim
From: Felipe Contreras @ 2009-10-12 14:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <20091012141334.GE9261@spearce.org>
On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> The problem is that gvim returns immediately
> ...
>> (BTW, this is in no way specific to Git, 99% applications calling
>> $EDITOR will expect the same behavior)
>
> The sad part is, every gvim user blames Git.
>
> Every single one of my coworkers who uses Linux had gvim as their
> default $EDITOR and found git commit working sometimes, and not
> working others. Since git was new to them, they blamed git, not
> their $EDITOR. They also felt insulted when I told them their
> $EDITOR was busted and should be replaced.
>
> Someone needs to whack gvim upside the head and fix that program
> to behave correctly.
Huh? What is wrong about 'gvim --nofork'?
--
Felipe Contreras
^ permalink raw reply
* Re: Supressing sorting of trees
From: Shawn O. Pearce @ 2009-10-12 14:20 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T152113-874@post.gmane.org>
Sal Mangano <smangano@into-technology.com> wrote:
> I am using Git in a non-standard way and need to make a few twaeks in my
> custom build. I have added a --nosort option to git mktree which will suppress
> the qsort of the tree.
>
> Will this break any other git functions? Are there any commands that assume
> trees are always sorted?
_YES IT BREAKS GIT_.
You cannot do this.
A Git repository whose trees are not sorted according to the Git
specific sort ordering is severly broken and most tools will fail
horribly on it.
Almost all code which reads trees assumes the names are sorted in a
specific order. These tools perform sorted merges against other tree
like structures. If the names are out of order the merge will fail.
`git fsck` will complain that the tree is not sorted properly.
Tools like `git log -- foo.c` will fail randomly because they break
out of the entry lookup as soon as they find a name that is after
foo.c, as they assume the tree is sorted.
I could go on. But there is no point.
Oh, and trust me when I say this, the tree sorting matters. Long ago
JGit had a bug where it didn't sort trees correctly all of the time
and we had a devil of a time tracking down that corruption.
--
Shawn.
^ permalink raw reply
* Supressing sorting of trees
From: Sal Mangano @ 2009-10-12 13:27 UTC (permalink / raw)
To: git
I am using Git in a non-standard way and need to make a few twaeks in my
custom build. I have added a --nosort option to git mktree which will suppress
the qsort of the tree.
Will this break any other git functions? Are there any commands that assume
trees are always sorted?
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 14:15 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120641sccf0e55xef4226269df78864@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> Which is the simplest way to backup a git repository after every commit?
Add a commit hook to push to another location, e.g.:
git remote add --mirror backup you@another.host:path/to/backup.git
cat >.git/hooks/post-commit
#!/bin/sh
git push backup
^D
chmod a+x .git/hooks/post-commit
--
Shawn.
^ permalink raw reply
* Re: git refuses to work with gvim
From: Shawn O. Pearce @ 2009-10-12 14:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: sebastian, git
In-Reply-To: <vpq8wfgg4u1.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> The problem is that gvim returns immediately
...
> (BTW, this is in no way specific to Git, 99% applications calling
> $EDITOR will expect the same behavior)
The sad part is, every gvim user blames Git.
Every single one of my coworkers who uses Linux had gvim as their
default $EDITOR and found git commit working sometimes, and not
working others. Since git was new to them, they blamed git, not
their $EDITOR. They also felt insulted when I told them their
$EDITOR was busted and should be replaced.
Someone needs to whack gvim upside the head and fix that program
to behave correctly.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Christian Himpel @ 2009-10-12 14:08 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120641sccf0e55xef4226269df78864@mail.gmail.com>
On Mon, Oct 12, 2009 at 08:41:15AM -0500, Israel Garcia wrote:
> Which is the simplest way to backup a git repository after every commit?
Using githooks(5) you can put a simple post-commit script in .git/hooks.
Maybe something like:
-->8--
#!/bin/sh
cp -a `pwd` `pwd`.`date +%s`
--8<--
Don't forget to make the script executable.
Regards,
chressie
^ permalink raw reply
* backup git repo on every commit
From: Israel Garcia @ 2009-10-12 13:41 UTC (permalink / raw)
To: git
Hi list, a simple question.
Which is the simplest way to backup a git repository after every commit?
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: [PATCH 3/3] user-manual: use 'fast-forward'
From: Michael J Gruber @ 2009-10-12 12:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530910120305o49ed7c74sf6a03097b1098a5f@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 12.10.2009 12:05:
> On Mon, Oct 12, 2009 at 8:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> It's a compound word.
>>
>> Thanks.
>>
>> This removes 7 out of 37 "fast forward" in Documentation/ directory. Are
>> we going to convert the remaining ones, too?
>
> Sure. Once I finish pushing the patches I have for user-manual, which
> is the one I'm interested right now.
>
And how about the other 40 or so in the remaining code?
In fact, hyphenated and separated forms of this compound noun are almost
evenly split, which reflects well upon the fact that there is no
clear-cut rule in US English (and neither in BE).
So, if you are suggesting a style we should define it and follow it
consistently. Our main source of definitions is the glossary. Now, that
has a truly salomonic solution:
fast forward
A fast-forward is a special type...
I suggest that this is the first place which needs attention, after
fixating the definition, maybe not just among the three of us, all
non-native speakers.
Michael
^ permalink raw reply
* Re: git refuses to work with gvim
From: Matthieu Moy @ 2009-10-12 12:43 UTC (permalink / raw)
To: sebastian; +Cc: git
In-Reply-To: <20091012134312.236d250e@gzip.coli.uni-saarland.de>
sebastian@CoLi.Uni-SB.DE writes:
> # git commit something
> fatal: no commit message? aborting commit.
> #
The problem is that gvim returns immediately, and lets the window
opened (try it in a terminal, "gvim foo.txt" returns immediately). Git
expects the commit message to be written and saved when $EDITOR
returns.
A quick search for "wait" in the man pages tells me that
GIT_EDITOR='gvim -f' git commit
works.
(BTW, this is in no way specific to Git, 99% applications calling
$EDITOR will expect the same behavior)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Michael J Gruber @ 2009-10-12 12:30 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530910120303y205e6cfeg80ba0dfd6ed5a045@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> The value is what it is, the --bool and --bool-or-int options don't
>>> specify the value type, just how it is interpreted. For example: a value
>>> of '1' can be interpreted as 'true'.
>>
>> It is not really about "interpreting", but about showing, isn't it?
>
> Unless you are setting it, instead of reading it.
>
I'd still suggest fixing the typo ("interpreted") and spelling out
"boolean".
Michael
^ permalink raw reply
* git refuses to work with gvim
From: sebastian @ 2009-10-12 11:43 UTC (permalink / raw)
To: git
Hi,
a few days ago I decided to switch from vim to gvim. To make use of
this in most cases I added :gui to my .vimrc which should make most
applications automatically switch to use gvim if they used the vim
command before.
But git seems to have problems with this. If I do now a "git commit
something" not the gui is opened but the console-version of vim. I
could live with that for git but if I now type some commit-message in
the console-version and do :x or :wq I get an error-message:
# git commit something
fatal: no commit message? aborting commit.
#
Also
# EDITOR=gvim git commit something
fatal: no commit message? aborting commit.
#
shows the same error.
Removing :gui from my .vimrc makes git behave normally again. I don't
know what the problem here is: vim or git or both toghether?
I already saw screenshots of people using git with gvim. So there is a
way to make them work together but what am I missing?
OS: Debian Lenny
vim: 7.1
git: 1.5.6.5
greetings
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Michael J Gruber @ 2009-10-12 12:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras venit, vidit, dixit 11.10.2009 22:43:
> So that users get to know how to configure git from the get-to with good
> practical example (color.ui = auto) that most people would probably like
> anyway.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 67ebffa..ff2563a 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -40,6 +40,33 @@ without any explanation.
> Finally, see <<todo>> for ways that you can help make this manual more
> complete.
>
> +[[getting-started]]
> +Getting started
> +=============
> +
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' (for the user) and 'repository' variables, where
> +'repository' variables take precedence over 'global' ones.
Well, you do talk about "system" below, and that's about it. Also, the
configuration is not really distributed among different locations. Most
newbies interested in a *D*VCS will misunderstand this (as git having
distributed configuration).
Alternative:
Git's default configuration can be changed on a system wide, global (per
user) and local (per repository) level, in the order of increasing
precedence.
> +
> +You would probably want to start setting up something useful:
> +------------------------------------------------
> +$ git config --global color.ui auto
> +------------------------------------------------
> +
> +This will make prettier the output of certain commands such as `git diff`, but
> +that's not important; what is important here is that `color.ui` has been
> +stored in the 'global' configuration.
This will make certain commands such as `git diff` use colors in the
output. What is important here is that the value `auto` for the option
`color.ui` has been stored in the 'global' configuration. Use `--system`
for the system wide configuration; specifying neither `--system` nor
`--global` makes `git config` access the local configuration.
> +
> +View and manually modify the configuration by opening `~/.gitconfig`:
View and manually modify the global configuration by opening
`~/.gitconfig` in your editor or using `git config --global --edit`:
> +------------------------------------------------
> +[color]
> + ui = auto
> +------------------------------------------------
> +
> +Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
I don't even think we should talk about locations here, "git config -e"
should be the first user's way to do it.
> +
> +More git configurations will be covered in the rest of the manual, if you want
> +to learn more look at linkgit:git-config[1] for details.
"Configurations" is ambiguous, it can be easily (mis)understood as
"types of configuration" (global, local etc.). Also, the above doesn't
really cover even one option. How about:
This manual covers many configuration options (such as `color.ui.`). For
more details on the `git config` command as well as all configuration
options see linkgit:git-config[1].
> [[repositories-and-branches]]
> Repositories and Branches
Cheers,
Michael
^ permalink raw reply
* Re: Questions about the new
From: Johannes Sixt @ 2009-10-12 12:19 UTC (permalink / raw)
To: Sergio; +Cc: git
In-Reply-To: <loom.20091012T115746-719@post.gmane.org>
Sergio schrieb:
> 1) Grafts and replace entries seem to operate on different aspects of the
> history graph. Grafts operate on arcs and replace on nodes.
Correct, but see below about tree and blob objects.
> As such, replace entries seem less general to me.
With grafts you can only change parenthood; with replace entries you can
change parenthood *and* all other aspects of a commit (message, author,
committer, dates).
Hence, replace entries are more general than grafts.
> Apparently, to simulate a graft with replace entries, you need to introduce
> extra commit objects. For instance, if object B has no parents, to pretend that
> it derives from some A, one needs to create an object B' equivalent to B but
> for the parents and then replace B by B', is this right?
Yes. Use git-cat-file + edit + git-hash-object as explained in this
message just the other day:
http://thread.gmane.org/gmane.comp.version-control.git/129727/focus=129907
> Conversely, I guess
> you can always simulate a replace entry with the graft mechanism, without the
> need to add any extra commit object. Am I overlooking something?
You cannot; see above. You can even replace tree objects and blob objects
using replace entries, IIUC, but you cannot do that with grafts.
> 2) Is it currently possible to use a replace entry to replace a commit object
> with nothing? Namely if B has A as its sole parent, is it possible to have a
> replace entry such as A-sha1 becomes null, to pretend that B is a hierarchy
> root?
Sure. Just make a commit object that does not have parents.
> 3) If I remember correctly, there was a reason why grafts were not considered
> suitable for transferring across repos. Can someone remind me about it? How
> does the replace mechanism address this issue?
The problem with grafts was that, for example, git-pack-objects obeyed the
graft, and could create a broken repository by removing grafted-away
objects. And since git-fsck also obeyed the graft, it did not notice the
breakage.
OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
never obey replace entries in the history. But they do keep track of them
(and the history that they reference) because they are referenced from the
refs/replace namespace.
-- Hannes
^ permalink raw reply
* Merge (or maybe rebase) question
From: Howard Miller @ 2009-10-12 11:55 UTC (permalink / raw)
To: git
Another how best to do this.
- I have my project all nicely in git with all the different releases
and versions in there going back years. Happy :-)
- I have a customer who has heaviliy modified an oldish version of the
software.
- I have identified the version that they modified and created a
branch in my git repo based on that version (i.e. what they would have
started with before modifying it)
- Their changes where applied to a simple download - no version
control, no nothing.
I now need to update them to the latest version of the software - can
git help me here or is it all a disaster?
As usual, any advice much appreciated.
PS. To make matters worse - their original is full of expanced CVS
$Id:$ tags so it will look to git like every single file has changed.
Damn you cvs!!!
^ permalink raw reply
* Re: Questions about the new
From: David Kågedal @ 2009-10-12 10:47 UTC (permalink / raw)
To: git; +Cc: Sergio
In-Reply-To: <loom.20091012T115746-719@post.gmane.org>
Sergio <sergio.callegari@gmail.com> writes:
> Hi,
>
> I read from the release notes of git 1.6.5 about the new "replace" mechanism.
> It is presented as "a replacement of the "grafts" mechanism, with the added
> advantage that it can be transferred across repositories."
Grafts allow you to change a little part of commit objects (the parent
relationship). Replacements allow (and require) you to change the whole
commit object. So obviously, anything you can do with grafts can be done
with replacements.
If you have your A-B-x-x-x history and want to remove A from the
history, you replace B with a commit object that is identical, except
for the missing parent link to A.
Replacements allow you do to other kinds of changes as well (comments,
authorshiips) and changes to other object(?), so it is a much more
general mechanism.
But I missed the discussion about it, so I'm not sure why it was felt it
was needed, or why the grafts mechanism wasn't enough.
--
David Kågedal
^ permalink raw reply
* Re: meaning of HEAD in context of filter-branch
From: bill lam @ 2009-10-12 10:41 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git, bill lam
In-Reply-To: <m27hv2s22f.fsf@igel.home>
On Sun, 11 Oct 2009, Andreas Schwab wrote:
> reasons). Prior to that, the $GIT_COMMIT environment variable will be
> ^^^^^^^^^^^
Thanks. This is what I should use.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* quote in help code example
From: bill lam @ 2009-10-12 10:29 UTC (permalink / raw)
To: git
In git man, eg. git help filter-branch
The code examples for command line or shell scripts inside .ft pairs
use (smart?) quote instead of single quotes, like
.ft C
git filter-branch --tree-filter ´rm filename´ HEAD
.ft
Is this intentional or just some configuration problem during
compiling.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Questions about the new
From: Sergio @ 2009-10-12 10:23 UTC (permalink / raw)
To: git
Hi,
I read from the release notes of git 1.6.5 about the new "replace" mechanism.
It is presented as "a replacement of the "grafts" mechanism, with the added
advantage that it can be transferred across repositories."
Since there is still little information about it, I would like to ask the
following:
1) Grafts and replace entries seem to operate on different aspects of the
history graph. Grafts operate on arcs and replace on nodes.
As such, replace entries seem less general to me.
Apparently, to simulate a graft with replace entries, you need to introduce
extra commit objects. For instance, if object B has no parents, to pretend that
it derives from some A, one needs to create an object B' equivalent to B but
for the parents and then replace B by B', is this right? Conversely, I guess
you can always simulate a replace entry with the graft mechanism, without the
need to add any extra commit object. Am I overlooking something?
2) Is it currently possible to use a replace entry to replace a commit object
with nothing? Namely if B has A as its sole parent, is it possible to have a
replace entry such as A-sha1 becomes null, to pretend that B is a hierarchy
root?
3) If I remember correctly, there was a reason why grafts were not considered
suitable for transferring across repos. Can someone remind me about it? How
does the replace mechanism address this issue?
Thanks,
Sergio
^ permalink raw reply
* Re: [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-12 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veip9jj6z.fsf@alter.siamese.dyndns.org>
On Mon, Oct 12, 2009 at 8:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It's a compound word.
>
> Thanks.
>
> This removes 7 out of 37 "fast forward" in Documentation/ directory. Are
> we going to convert the remaining ones, too?
Sure. Once I finish pushing the patches I have for user-manual, which
is the one I'm interested right now.
--
Felipe Contreras
^ 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