* Re: How do I..?
From: Peter Harris @ 2008-12-17 23:44 UTC (permalink / raw)
To: Dylan Martin; +Cc: git
In-Reply-To: <e1a4c7f60812171516h7b7bb1fem35dfc6f30747a740@mail.gmail.com>
On Wed, Dec 17, 2008 at 6:16 PM, Dylan Martin wrote:
> Before I switched to git, I played around with SVN a bit, and started
> a few tiny SVN repos for various scripts I was working on. So, I know
> have one git repo with %90 of my stuff and a handful of SVN repos.
> I'd like to be able to add the SVN repos as subdirectories inside my
> git repo. I've found lots of pages describing how to convert an SVN
> repo into a _new_ git repo, but I haven't found anything yet about
> importing the contents of an SVN repo as a subdirectory of an
> _existing_ git repo.
You could convert each SVN repo into its own temporary git repo, then
use the subtree merge strategy to combine the git trees:
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Peter Harris
^ permalink raw reply
* Re: How do I..?
From: Miklos Vajna @ 2008-12-17 23:49 UTC (permalink / raw)
To: Dylan Martin; +Cc: git
In-Reply-To: <e1a4c7f60812171516h7b7bb1fem35dfc6f30747a740@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Wed, Dec 17, 2008 at 03:16:59PM -0800, Dylan Martin <dmartin@sccd.ctc.edu> wrote:
> Sorry if this is a dumb question. I've poked around the docs and
> tried the google searches I could think of, but I don't even know what
> kind of search terms one would use in trying to answer this.
>
> I'm a sysadmin and I've got a big monolithic git repo of all my
> scripts, documents, etc... It used to be a CVS repo but I converted
> it to git a while ago.
> Before I switched to git, I played around with SVN a bit, and started
> a few tiny SVN repos for various scripts I was working on. So, I know
> have one git repo with %90 of my stuff and a handful of SVN repos.
> I'd like to be able to add the SVN repos as subdirectories inside my
> git repo. I've found lots of pages describing how to convert an SVN
> repo into a _new_ git repo, but I haven't found anything yet about
> importing the contents of an SVN repo as a subdirectory of an
> _existing_ git repo.
I would convert each repo to git, then merge them using subtree merge.
See Documentation/howto/using-merge-subtree.txt.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int
From: Robin Rosenberg @ 2008-12-18 0:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081217224844.GK32487@spearce.org>
onsdag 17 december 2008 23:48:44 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > If not dates past 2038 will be parsed the wrong way when
> > parsed into a RevCommit or RevTag object.
>
> Uhm, sure.
>
> But there's also the commitTime field in RevCommit, its used to
> sort commits during walking. In 2038 that will also overflow.
Ok, but that's not used for display purposes, which what I saw. How
huge is the cost of a long here. Most processor handle longs
well today, though many megs of them will hurt the cache.
> Also, if you search the code for '2038' you'll find a remark
> about the year 2038 in DirCacheEntry.smudgeRacilyClean. Last
> I looked at the git sources I think this field in the index is
> treated as a signed time_t so we can't set the high bits and
> extend it out another 60+ years.
That is another time stamp. It is a file time stamp, which we
never store in the Git object database. The index can be revised over time since
it is purely local structure. If it weren't for the need to operate
with C Git in the same repo we could have used a different format,
and nobody would notice. (The first jgit versions used a different
index structure).
time_t is signed, but it is also 64 bit on 64-bit linux so it doesn't overflow in 2038.
$ cev 'printf("sizeof time =%d\n",sizeof(time_t));'
sizeof time =8
> I'd rather just tag the fields with "2038" so we can search for
> them in the future. Like say this:
There should be a comment on the commitTime field too if we choose
that option.
-- robin
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Geoffrey Lee @ 2008-12-18 0:53 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229540813648-1669264.post@n2.nabble.com>
On Wed, Dec 17, 2008 at 11:06 AM, Henk <henk_westhuis@hotmail.com> wrote:
>
> This is a shameless announcement of my latest personal project; Git
> Extensions. Git Extensions is a Tortoise-like windows shell extension for
> git. Yesterday I finished version 0.9, the first stable release. I included
> about all git commands I know about, so I think it is pretty complete but
> I'm open to suggestions.
I'm curious... How are you dealing with Windows' low limit on icon
overlay handlers? TortoiseSVN already hits the system limit, hence
their development of TortoiseOverlay to provide a common icon overlay
handler for all the Tortoise* projects. Have you gotten GitExtensions
to work side-by-side with TortoiseSVN? You might want to take a look
at this document, username "guest" and no password:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseOverlays/Documentation.txt
-Geoffrey Lee
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johan Herland @ 2008-12-18 1:00 UTC (permalink / raw)
To: git; +Cc: Gili Pearl, Johannes Sixt
In-Reply-To: <897592.56642.qm@web112219.mail.gq1.yahoo.com>
On Wednesday 17 December 2008, Gili Pearl wrote:
> > From: Johan Herland <johan@herland.net>
> > On Wednesday 17 December 2008, Gili Pearl wrote:
> > > But what if K-L-M conflict with C-D? The one who should take care
> > > about it is the mid-level1 maintainer (or possibly one of the
> > > low-level1 maintainers).
> >
> > If there is a merge conflict, mid-level1 maintainer will typically
> > merge D and M into a new merge commit N:
> >
> > top-level : A----B----C----D
> > \ \
> > \ \
> > mid-level1: K----L----M----N
>
> There's one thing that still bothers me and I'd like to understand.
> What if someone looks both on top-level repo and mid-level1 repo, and he
> want to diff some local commit X against commit D. I didn't try it, but I
> wonder how git knows against which D to compare? On the top-level D means
> A-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what
> git-log on mid-level shows). I'm probably missing something here...
> commit id cannot represent two different histories, right?
D will always be the same commit in both top-level repo and mid-level1 repo.
Remember that D precedes the merge commit N, so D is not changed by the
merge at all (then we could no longer call it D).
The diagram above is slightly misleading, in that it does not say whether
the merge commit N has been pulled into the top-level repo or not. Here are
more descriptive illustrations:
A) Before the merge:
A----B----C----D <-- top-level
\
\
K----L----M <-- mid-level1
B) After mid-level1 has done the merge
A----B----C----D <-- top-level
\ \
\ \
K----L----M----N <-- mid-level1
C) After top-level has pulled the merge from mid-level1 (assuming top-level
has done nothing in the meantime, and can fast-forward to N)
A----B----C----D
\ \
\ \
K----L----M----N <-- mid-level1 & top-level
> > ...and then ask top-level maintainer to merge N (which should have no
> > conflicts by now). The merge can also be done by low-level1 developer.
>
> How can it be done by low-level1? you mean by bypassing mid-level and
> merging top-level directly?
No. low-level1 will do the merge commit in his repo (typically by creating a
new branch at M (thus keeping X & Y out of the way), and then merging D
into this new branch to produce N), and will then ask mid-level1 to pull
the merge into her repo. From there, the situation is similar to the above
diagrams.
In principle, it's possible for low-level1 to ask top-level directly to pull
his merge commit, but this is probably frowned upon, because it breaks the
project conventions (although git itself has no problem with this).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Tim Visher @ 2008-12-18 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpvajtmd.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> How about omitting the "git commit" and do "git checkout PATH" after you
> are done with the staging? IOW, (1) above.
Huh. I guess I was under the impression that doing the `git checkout
PATH` would destroy the staged content as well as the unstaged. This
isn't the case?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Frank Li @ 2008-12-18 1:57 UTC (permalink / raw)
To: Tim Visher; +Cc: Henk, git
In-Reply-To: <c115fd3c0812171204ve560583w4c76aac0ac08d8ae@mail.gmail.com>
Great Work!
TortoiseGit start late. But it reuse many TortoiseSVN work.
I believe TortoiseGit can catch.
Best regards
Frank Li
2008/12/18 Tim Visher <tim.visher@gmail.com>:
> On Wed, Dec 17, 2008 at 2:06 PM, Henk <henk_westhuis@hotmail.com> wrote:
>>
>> This is a shameless announcement of my latest personal project; Git
>> Extensions. Git Extensions is a Tortoise-like windows shell extension for
>> git. Yesterday I finished version 0.9, the first stable release. I included
>> about all git commands I know about, so I think it is pretty complete but
>> I'm open to suggestions.
>
> Nice! With all of this TortoiseGit-like activity we're bound to have
> something pretty usable pretty quickly! :) I'll have to check out the
> sources soon and see if I can get involved. Maybe any of the
> developers who were planning on working on TortoiseGit could
> officially move over to Git Extensions since it seems to be much
> further along?
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Mike Coleman @ 2008-12-18 2:18 UTC (permalink / raw)
To: git
It's so cold here my car wouldn't start this morning, so I feel
fortunate to have these flames to keep me warm! :-)
I still find git-diff's unsolicited invocation of $PAGER a bit
jarring, but I also find that I like it. It has a sort of Windows-ish
feel to it (am I straying from the true path?). It's convenient,
though honestly "git-diff|l" would only be two extra characters. From
a UI perspective, the oddest thing about it is that all (not, in
fact?) of the other git programs which might also produce lengthy
output *don't* invoke $PAGER--git-status particularly comes to mind.
There are a large number of Unix programs that would be more
convenient if their output was automatically paged, but I'm not sure
it'd be better if they were all changed to do this. (The best analog
I can think of where this seems desirable is man(1).)
To me, the most important nugget from the original complaint was that
git-diff sends its error messages to stdout. I understand why it
might be done, but I'd worry about losing the stderr diagnostic for a
command that matters. [I've been playing around with this for a few
minutes trying to see errors going to stdout and I can't reproduce
it--I wonder if they really do.]
Regarding the emacs complaint, as an emacs user I'd say I'm not
surprised this didn't quite work right. In the particular case of the
compilation buffer, I wonder if the solution isn't to just unset TERM,
the existence of which (together with the fact that there's a pty)
could be taken as an invitation for the subordinate process to start
doing awful raw-terminal things. (Similar logic applies to the
DISPLAY variable.) Like Junio, I also eschew doing terminal emulation
inside of emacs.
Good evening from the icy midwest,
Mike
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Junio C Hamano @ 2008-12-18 2:26 UTC (permalink / raw)
To: Mike Coleman; +Cc: git
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>
"Mike Coleman" <tutufan@gmail.com> writes:
> To me, the most important nugget from the original complaint was that
> git-diff sends its error messages to stdout. I understand why it
> might be done, but I'd worry about losing the stderr diagnostic for a
> command that matters. [I've been playing around with this for a few
> minutes trying to see errors going to stdout and I can't reproduce
> it--I wonder if they really do.]
They indeed did but it has hopefully been fixed. See a833502 (pager: do
not dup2 stderr if it is already redirected, 2008-12-15).
> ... Like Junio, I also eschew doing terminal emulation
> inside of emacs.
Come to think of it, it may have been from you that I picked up the trick
of setting PAGER to cat inside an Emacs environment.
> Good evening from the icy midwest,
Good evening from rainy and chilly SoCal.
^ permalink raw reply
* Re: Git Notes idea.
From: Johannes Schindelin @ 2008-12-18 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Govind Salinas, Git Mailing List
In-Reply-To: <7voczaobhb.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 17 Dec 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ... But the main point still stands: you go from commit to note, not
> > from note to commit. And this is in stark contrast to tags, where you
> > go from tag to commit, _not_ from commit to tag.
> >
> > That is a fundamental _difference_ between tags and notes, so that I
> > refuse to accept the notion of notes being a generalized form of tags.
>
> Hmm, how would you explain things like "git describe" (and "name-rev")?
Programs?
Ciao,
Dscho
^ permalink raw reply
* Re: Git - index-pack missing
From: Junio C Hamano @ 2008-12-18 3:15 UTC (permalink / raw)
To: Michael Boutros; +Cc: git
In-Reply-To: <54F47863-AF55-4FB7-8A43-A4253E1F782C@michaelbutros.com>
Michael Boutros <me@michaelboutros.com> writes:
> I'm trying to clone a repository for the first time on a hosting
> account that just got setup with Git. However, the problem is that for
> some reason there is no git-index-pack. I cannot find any reason that
> that one particular command would not be installed, but for some
> reason that seems to be the case.
You may want to study output from "git help --all" to see if there is
anything *else* that is missing. You did not say which version of git you
use, and how it was built and installed with which non-standard options
and in what way, so it is hard to guess what is going on.
Perhaps:
$ cd ~root
$ grep 'rm .*index-pack' .history .bash_history
could help locating the cause of breakage, but there are other ways to
break your installation, so...
> Has anyone ever heard of anything like this?
Not me.
^ permalink raw reply
* Re: [PATCH] gitk: force focus to main window
From: Johannes Schindelin @ 2008-12-18 3:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <18761.29020.237388.687560@cargo.ozlabs.ibm.com>
Hi,
On Thu, 18 Dec 2008, Paul Mackerras wrote:
> Johannes Sixt writes:
>
> > On msysGit, the focus is first on the (Tk) console. This console is
> > then hidden, but keeps the focus. Work around that by forcing the
> > focus onto the gitk window.
>
> Hmmm, I don't like doing focus -force unconditionally on all platforms.
> I hate it when applications decide they know best and override what the
> window manager decides.
>From my previous experience with my patches to gitk, I did not expect
otherwise. That is why I did not even bother with this one.
> At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> is a windows thing, isn't it?)
Yeah, because on other platforms, when you start gitk, you don't want it
to take focus. Yeah, right.
Ciao,
Dscho
^ permalink raw reply
* Re: Git - index-pack missing
From: Jeff King @ 2008-12-18 3:16 UTC (permalink / raw)
To: Michael Boutros; +Cc: git
In-Reply-To: <54F47863-AF55-4FB7-8A43-A4253E1F782C@michaelbutros.com>
On Wed, Dec 17, 2008 at 06:40:40PM -0500, Michael Boutros wrote:
> I'm trying to clone a repository for the first time on a hosting account
> that just got setup with Git. However, the problem is that for some reason
> there is no git-index-pack. I cannot find any reason that that one
> particular command would not be installed, but for some reason that seems
> to be the case.
How did you install git? From a binary package, from a tarball, from a
clone? If built, how did you build it? Any config.mak options, did you
use ./configure, etc? What version of git is it?
Is it possible for you to strace the clone process to see where it is
trying to find index-pack? Something like:
strace -f -e execve git clone
should do it.
> Has anyone ever heard of anything like this? Is my only option to
> completely scrap Git and try again?
That might work, but if this is a bug in the build or installation
system, it will be nice to track it down before you scrap the current
setup.
-Peff
^ permalink raw reply
* Re: rsync deprecated?
From: Junio C Hamano @ 2008-12-18 3:20 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812180041.10312.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> in the "Merging external work" section of the gitcore-tutorial it is
> stated that the rsync transport is deprecated. The description was added
> in commit 914328a (Update tutorial., 2005-08-30) together with the
> "deprecated" note. Having never heard/read this before and since this
> commit is quite old, I wonder if it is still the case or there was a
> solution for this problem.
Sorry, I do not quite understand what you perceive as "this problem".
It has been deprecated for too long a time. Maybe it is time to remove
the support, instead of carrying the deprecated command forever? Is that
the problem you are talking about?
I tend to agree that rsync transport way outlived its usefulness, and not
maintained at all. There may be unnoticed and undiagnosed bugs lurking,
but nobody knows about it because nobody uses it.
But the next release (1.6.1) won't be a good timing for removal. Perhaps
we can make an announcement now that it will be removed in a future major
update, and actually remove it in 1.7.0 or so.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Johannes Schindelin @ 2008-12-18 3:22 UTC (permalink / raw)
To: Mike Coleman; +Cc: git
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Mike Coleman wrote:
> I still find git-diff's unsolicited invocation of $PAGER a bit
> jarring, but I also find that I like it.
It might have its reason in that it follows the common flow, where
interactive use of _any_ diff program is _just useless_ unless piped to a
pager.
And no, redirecting to a file is not interactive.
Can we please stop with those bogus and pointless, not to mention
uninformed, discussions about design decisions that have been verified to
be useful, or at least not harmful in any way, for a _long_, _long_ time?
The git list is high volume already, but at least so far it was high
signal/noise ratio.
Let's keep it that way,
Dscho
^ permalink raw reply
* Re: [PATCH] gitk: force focus to main window
From: Jeff King @ 2008-12-18 3:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Mackerras, Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812180413240.14632@racer>
On Thu, Dec 18, 2008 at 04:14:25AM +0100, Johannes Schindelin wrote:
> > At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> > is a windows thing, isn't it?)
>
> Yeah, because on other platforms, when you start gitk, you don't want it
> to take focus. Yeah, right.
That is _exactly_ what I want on my platform: no window should steal the
focus when I am in the middle of typing in some other window. And to
that end, my window manager does not shift the focus until I tell it to
do so.
So yes, this patch _does_ break at least my setup. But more importantly,
it is an application making a decision about focus policy that should be
made by the window manager. I understand that the window manager in
Windows sucks, and that this is a workaround that makes things better
there. But please don't inflict this braindeadedness on the rest of us.
-Peff
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Jeff King @ 2008-12-18 3:31 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763lixyps.fsf_-_@jidanni.org>
On Thu, Dec 18, 2008 at 05:45:35AM +0800, jidanni@jidanni.org wrote:
> Gentlemen, I have found the solution to your problem.
>
> Unbundle git-diff and $PAGER.
If you are going to argue this, please at least go back and read the
numerous times it has been brought up in the past on the list archive.
The last discussion ended up showing that some people really like the
automatic pager for some commands, and some people really detest it.
So I implemented 4e10738 (Allow per-command pager config, 2008-07-03),
and now you can do:
git config pager.diff false
and be happy (or, as you obviously disocvered, simply unsetting
core.pager will disable all).
-Peff
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Nanako Shiraishi @ 2008-12-18 3:34 UTC (permalink / raw)
To: Tim Visher; +Cc: Junio C Hamano, git
In-Reply-To: <c115fd3c0812171722g93dbeefw2fb5bf7641dfe394@mail.gmail.com>
Quoting "Tim Visher" <tim.visher@gmail.com>:
> On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> How about omitting the "git commit" and do "git checkout PATH" after you
>> are done with the staging? IOW, (1) above.
>
> Huh. I guess I was under the impression that doing the `git checkout
> PATH` would destroy the staged content as well as the unstaged. This
> isn't the case?
A short answer is "no it is not the case."
I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.
This is a patch to clarify the sentence.
-- 8< -- Cut Here -- 8< --
Subject: Clarify documentation of "git checkout <tree-ish> paths" syntax
The SYNOPSIS section of the manual writes:
git checkout [options] [<tree-ish>] [--] <paths>...
but the DESCRIPTION says that this form checks the paths out "from the
index, or from a named commit." A later sentence refers to the same
argument as "<tree-ish> argument", but it is not clear that these two
sentences are talking about the same command line argument for first-time
readers.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 168333a..bbdfa40 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -27,7 +27,7 @@ the first namespace level.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
-the index file, or from a named commit. In
+the index file, or from a named <tree-ish> (most often a commit). In
this case, the `-b` options is meaningless and giving
either of them results in an error. <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH] gitk: force focus to main window
From: Paul Mackerras @ 2008-12-18 4:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812180413240.14632@racer>
Johannes Schindelin writes:
> > At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> > is a windows thing, isn't it?)
>
> Yeah, because on other platforms, when you start gitk, you don't want it
> to take focus. Yeah, right.
No - on other platforms I have a window manager that gives focus to
new applications automatically. Or, if I don't want new applications
to grab the focus, I tell the window manager that that's what the
policy should be. Either way the application shouldn't forcibly and
unilaterally grab the focus.
I'm prepared (predisposed, even :-) to believe that windows sucks, so
I'll take the patch if it only affects windows.
Paul.
^ permalink raw reply
* Re: rsync deprecated?
From: Markus Heidelberg @ 2008-12-18 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuei2xw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 18.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > in the "Merging external work" section of the gitcore-tutorial it is
> > stated that the rsync transport is deprecated. The description was added
> > in commit 914328a (Update tutorial., 2005-08-30) together with the
> > "deprecated" note. Having never heard/read this before and since this
> > commit is quite old, I wonder if it is still the case or there was a
> > solution for this problem.
>
> Sorry, I do not quite understand what you perceive as "this problem".
The problem described in the rsync section in gitcore-tutorial:
"can produce unexpected results when you download from the public
repository while the repository owner is uploading into it via rsync
transport. Most notably, it could update the files under refs/ which
holds the object name of the topmost commits before uploading the
files in objects/ - the downloader would obtain head commit object
name while that object itself is still not available in the
repository."
I only thought about git itself uploading into and downloading from the
repository with push and fetch, respectively. And wondered where the
problem with the order of refs and objects was. But I just realized, it
can of course be uploaded with plain rsync, too.
> It has been deprecated for too long a time. Maybe it is time to remove
> the support, instead of carrying the deprecated command forever? Is that
> the problem you are talking about?
Yes, this is the answer to my question. I thought maybe it's not
deprecated anymore, because the only place where it is called so, is
gitcore-tutorial.
^ permalink raw reply
* Re: [PATCH] Add git-edit-index.perl
From: Jeff King @ 2008-12-18 4:37 UTC (permalink / raw)
To: Neil Roberts; +Cc: git
In-Reply-To: <20081217204749.GA18261@janet.wally>
On Wed, Dec 17, 2008 at 08:47:49PM +0000, Neil Roberts wrote:
> This script can be used to edit a file in the index without affecting
> your working tree. It checkouts a copy of the file to a temporary file
> and runs an editor on it. If the editor completes successfully with a
> non-empty file then it updates the index with the new data.
Hmm. Neat idea. I have used add-interactive's "e"dit patch option to do
a similar thing, but it is often unwieldy (e.g., just yesterday I had a
patch that removed about 30 lines and added 1 -- rather than munging the
diff, it would have been simpler to re-add the line in a staged
version).
Thinking out loud: One thing that would make this more useful would be
providing the content of the work tree file in some way. Like seeing the
whole file but with "conflict markers" showing two versions of each
hunk, like:
a line in both files
<<<<<<< staged
a line only in the staged version
=======
a line only in the working tree version
>>>>>>> working tree
and then you can edit around that. Of course, then you _have_ to
edit every hunk since you have just stuck the conflict marker cruft. I
guess a savvy user could just open both versions in their editor and
pull content from one buffer to the other other.
> This is useful to fine tune the results from git add -p. For example
> sometimes your unrelated changes are too close together and
> git-add--interactive will refuse to split them up. Using this script
> you can add both the changes and later edit the index file to
> temporarily remove one of the changes.
Have you tried using the edit-patch option in "git add -p"? I'm curious
if you would like that better for your cases, or if you find this way
more natural.
> .gitignore | 1 +
> Makefile | 1 +
> git-edit-index.perl | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++
I have to wonder if this wouldn't be better as part of
git-add--interactive? I guess technically you aren't "adding" from the
work tree since it is purely looking at the staged version. But it seems
to be part of the same workflow, as you are munging content in the
index.
> +sub check_file_size {
> + my ($fn) = @_;
> + my ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size,
> + $atime, $mtime, $ctime, $blksize, $blocks) = stat($fn);
> +
> + $size;
> +}
FYI, a shorthand for this is:
(stat $fn))[7];
or you may consider:
use File::stat;
stat($fn)->size;
which is nicely readable.
> + unless (system($editor, $tmp_fn) == 0
> + && check_file_size($tmp_fn)) {
> + # If the editor failed, the file has disappeared or it
> + # has zero size then give up
> + delete_temp_files(@file_list);
> + die("Editor failed or file has zero size");
I guess you are aborting on a zero-size file to allow the user a chance
to say "oops, I want to scrap the changes I've saved so far". But you
are disallowing making a file empty by this process. Which I guess is
not all that common, but it still seems restrictive. I wonder if asking
for confirmation might make more sense.
Also, does it make sense to delete the temp files if the editor failed?
The user may have put work into the file, but we are not successfully
updating the index; so we may be deleting useful work that could be
recovered.
> + unless (defined($hash) && $hash =~ /\A[0-9a-f]{40}\z/) {
> + delete_temp_files(@file_list);
> + die("Failed to add new file");
Again, if we fail to hash for whatever reason, we should not delete the
useful work that the user might have done.
-Peff
^ permalink raw reply
* Re: [PATCH] Enable threaded delta search on Mac OS X/Darwin
From: Junio C Hamano @ 2008-12-18 6:02 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: git
In-Reply-To: <1229502025-15340-1-git-send-email-arjen@yaph.org>
I will apply this one, as I do not have an access to these machines and
there is no point for me to be holding onto it. People who may be
affected, please test and report.
^ permalink raw reply
* Re: [PATCHv5 2/3] gitweb: add patches view
From: Junio C Hamano @ 2008-12-18 6:09 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1229422290-6213-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> sub git_commitdiff {
> my $format = shift || 'html';
> + my %params = @_;
> ...
> + if ($params{-single}) {
> + push @commit_spec, '-1';
> + } else {
> + if ($patch_max > 0) {
> ...
> + }
> @@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
>
> # format-patch-style patches
> sub git_patch {
> + git_commitdiff('patch', -single=> 1);
> +}
Hmm, if you are changing the interface this way, wouldn't it make more
sense to also do this?
git_commitdiff(--format => 'patch', --single => 1);
git_commitdiff(--format => 'html');
^ permalink raw reply
* Suggestion: better error reporting when setting HEAD
From: Francois Marier @ 2008-12-18 5:58 UTC (permalink / raw)
To: git; +Cc: sam.vilain
(Please CC me on your replies, thanks)
If you take any valid git repo and then do the following:
git symbolic-ref HEAD master
(instead of "git symbolic-ref HEAD refs/heads/master")
then other git commands (e.g. "git log") will return this error message:
fatal: Not a git repository
I'd like to suggest two "usability" improvements:
1- changing the error message to explain why the directory is no longer
considered a git repo. Maybe something along the lines of:
fatal: Invalid reference in .git/HEAD
2- To prevent this error from happening in the first place, git-symbolic-ref
could refuse to change HEAD to a non-existent ref.
Cheers,
Francois
^ permalink raw reply
* [PATCHv6 0/4] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sixth iteration of the patch view in gitweb, that exposes the
git-format-patch output directly, allowing patchset exchange via gitweb.
As suggested by Junio, the call pattern for git_commitdiff is changed to
use named parameters even for the first parameter (-format).
Giuseppe Bilotta (4):
gitweb: add patch view
gitweb: change call pattern for git_commitdiff
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb/gitweb.perl | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 108 insertions(+), 1 deletions(-)
^ 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