* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Drew Northup @ 2011-01-20 13:53 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jonathan Nieder, Junio C Hamano, Git List, David Barr,
Sverre Rabbelier
In-Reply-To: <20110120045046.GB9493@kytes>
On Thu, 2011-01-20 at 10:20 +0530, Ramkumar Ramachandra wrote:
> Hi,
>
> Jonathan Nieder writes:
> > Junio C Hamano wrote:
> > > Ramkumar Ramachandra <artagnon@gmail.com> writes:
> > > Just thinking aloud, but is it possible to write a filter that converts an
> > > arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> > > referenced blobs by inlining all the blobs?
> >
> > to avoid complexity in the svn fast-import backend itself.
> > (Complicating detail: such a filter would presumably take responsibility
> > for --export-marks, so it might want a way to retrieve commit marks
> > from its downstream.)
>
> This filter will need to persist every blob for the entire lifetime of
> the program. We can't possibly do it in-memory, so we have to find
> some way to persist them on-disk and retrieve them very
> quickly. Jonathan suggested using something like ToyoCabinet earlier-
> I'll start working and see what I come up with.
Is it worth including the extra dependency? Most systems that I'm in
frequent contact with already have some lightweight BDB implementation
already. I don't currently know of any with TokyoCabinet (or
KyotoCabinet for that matter) already in place. Besides, if all you're
doing is persisting blobs that you're likely to write out to disk
eventually anyway you might as well just do so once you have them and
keep an "index" (not to be confused with the Git Index, just lacking a
better word right now) of what you have in some standard in-memory
format (a heap?). From there you can build each commit into the Git
Index in the proper order once you have the required parts for
each--perhaps even re-using the blobs you've already dumped to disk
(mv'ing them or something).
Granted, there's a good likelihood that I'm missing something here, but
I don't see the point of adding external complexity (beyond what you're
currently stuck dealing with).
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Thomas Rast @ 2011-01-20 13:03 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <ih95fg$62b$1@dough.gmane.org>
Stephen Kelly wrote:
> Why does git not have a bug tracker?
http://thread.gmane.org/gmane.comp.version-control.git/136500
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Thomas Rast @ 2011-01-20 12:52 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git, Ramkumar Ramachandra, Erik Faye-Lund, Jonathan Nieder
In-Reply-To: <ih95il$62b$2@dough.gmane.org>
Stephen Kelly wrote:
>
> Is this patch going to become part of git, or is it in already?
>
> If not it will probably just get lost because there is no issue tracker.
Discussion stalled without an agreement that any patch proposed is
"good", so if it ends here it will be dropped.
You could probably help getting closer to a solution by:
* Not dropping Cc's all the time. I saw this email just by chance.
* Stating *why* this cannot be solved in any other way on the KDE
end. So far you only said
> > Is it impossible to fix this on the KDE side? I would think a
> > many-to-one mapping from committer identities to bugzilla account
> > names could be a useful thing to have in any case.
>
> I asked that before coming here, and apparently that is not possible.
My gut feeling is that a footer line in the commit along the lines
of
Bugzilla-Id: Registered Name <registered.email@example.com>
would work. I suspect others have a similar feeling. A good case
why this is not a feasible solution for (presumably) border cases
like you would help get rid of it.
* Replying to e.g.
http://mid.gmane.org/201101111542.15185.trast@student.ethz.ch
with (ideally better) ideas of what the semantics should be. My
assessment is that it either conflicts with user expectations or
with established git-config mechanisms of how the various files
override each other.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2] Introduce new configuation option to override committer information
From: Stephen Kelly @ 2011-01-20 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <1294568989-5848-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Currently, there is no way to set committer information on a
> per-repository basis. The 'user.name' and 'user.email' configuration
> options set both author and committer information. To solve this,
> introduce 'user.committername' and 'user.committeremail' configuration
> options to override committer name and email respectively.
Is this patch going to become part of git, or is it in already?
If not it will probably just get lost because there is no issue tracker.
Thanks,
Steve.
^ permalink raw reply
* Re: Creating remote branch called HEAD corrupts remote clones
From: Stephen Kelly @ 2011-01-20 11:14 UTC (permalink / raw)
To: git
In-Reply-To: <ih1449$ul6$1@dough.gmane.org>
Stephen Kelly wrote:
>
> Hi,
>
> On Friday we had an issue where a developer pushed a branch called HEAD to
> the remote server. The result was that other developers could not pull or
> push.
Does anyone have any thoughts/response on this?
Why does git not have a bug tracker?
Steve.
^ permalink raw reply
* Re: EOL strangeness
From: René Scharfe @ 2011-01-20 8:54 UTC (permalink / raw)
To: Graham Sanderson; +Cc: git
In-Reply-To: <AANLkTiknxMh_OophKWsqkYO2C+PsfF0ZnNXKLbheM4wF@mail.gmail.com>
Am 17.01.2011 20:56, schrieb Graham Sanderson:
> Apologies if someone has answered this before:
>
> So we have moved some big teams over to git (awesome thx), and have
> been using the msysgit default core.autocrlf=true on Windows, and
> making sure text files are LF on other platforms
>
> However we do continue to have a few problems with people storing CRLF
> in the repository (partly because of lack of understanding, and partly
> it seems because of eGit on windows which ignores core.autocrlf).
>
> Anyway, this much is all fine, and we can fix; what I don't understand
> is why for files stored as CRLF in the repository it seems
> indeterminate when or if they show up locally modified (on my window
> box with core.autocrlf = true) when I pull them from the repository. I
> assume the idea is that that they "would be" modified if I were to
> check them in, since they would be converted to LF, however this only
> happens sometimes and for a seemingly random subset of the files
> stored incorrectly.
>
> It also seems to depend on the state of the local index, as recreating
> the local index often changes the set of files that are displayed this
> way (even without any changes to the files), and it also seems to be
> different on different machines (perhaps based on when they happened
> to pull code).
>
> If anyone can give me a quick mental picture of how this is supposed
> to work (i.e. at what time the eol conversions are considered) then
> that'd be great... otherwise I guess I'll go dig in the code.
Perhaps this recent thread is of interest to you, even though it's on a
slightly different topic and inconclusive:
http://thread.gmane.org/gmane.comp.version-control.git/163794
It would be nice to have the expectations in your case codified in a
test script -- based on the documentation, if possible.
René
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Ramkumar Ramachandra @ 2011-01-20 6:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110120054813.GB4770@burratino>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > The functionality to persist blobs that are refenced by
> > marks probably shouldn't be in svn-fe at all.
>
> Do you mean svn-fi?
Yeah. Sorry about the typo. Just to make it clear:
svn-fi should only ever support inlined blobs. For older streams,
there's an extra overhead- it'll have to be chained along with a
helper program that transforms the stream to inline all the blobs.
> > This filter will need to persist every blob for the entire lifetime of
> > the program.
>
> Depending on the interface, couldn't it be possible to rely on svn for
> the content of blobs that have already been exported? If so, one
> would only need a place to stash (1) a mapping from mark numbers to
> (svn rev, path) pairs and (2) the full text of blobs that have not
> been exported as part of a rev yet.
Oh yes. We discussed this on IRC :) I'm just afraid that it won't be
fast enough- my idea is to essentially use `svnrdump dump` to replay
the blobs in a certain (path, revision); let me know if you think
there's a quicker way.
-- Ram
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Jonathan Nieder @ 2011-01-20 5:48 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110120045046.GB9493@kytes>
Ramkumar Ramachandra wrote:
> The functionality to persist blobs that are refenced by
> marks probably shouldn't be in svn-fe at all.
Do you mean svn-fi?
> This filter will need to persist every blob for the entire lifetime of
> the program.
Depending on the interface, couldn't it be possible to rely on svn for
the content of blobs that have already been exported? If so, one
would only need a place to stash (1) a mapping from mark numbers to
(svn rev, path) pairs and (2) the full text of blobs that have not
been exported as part of a rev yet.
Cheers,
Jonathan
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Jonathan Nieder @ 2011-01-20 5:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <7vtyh4smer.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Just thinking aloud, but is it possible to write a filter that converts an
> arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> referenced blobs by inlining all the blobs?
A few details to watch out for:
- A mark, as in
M 100644 :1 path/to/file
can refer to a blob from a previous import. A mark can even refer
to a manually prepared marks file.
- The syntax
M 100644 0409ac9fd3f1ea36680189e07116e58b2630ccad path/to/file
refers to a blob that might not have been mentioned elsewhere in the
stream. This is the variant used by "git fast-export --no-data" to
avoid transferring blob data. (In general, non-git backends would
presumably use something other than git blob IDs if they use this
feature. A filter of the kind we are describing would probably pass
them through.)
These datarefs can be acquired out of band (probably not a big deal)
or by using the "ls" command to copy from a previous revision:
> ls :3 "path/to/other/file"
100644 blob 0409ac9fd3f1ea36680189e07116e58b2630ccad git.c
> M 100644 0409ac9fd3f1ea36680189e07116e58b2630ccad path/to/file
- The cat-blob command ("cat-blob :1") allows frontends to request
the content of a previously imported blob (presumably in order to
apply a delta to it).
So while something like the filter you describe seems possible, it
cannot be as simple as
mkfifo replies &&
fast-export-frontend 3<replies |
inline-blobs |
fast-import-backend --cat-blob-fd=3 <args> 3>replies
for general <frontend> and <backend>. The frontend might try to cat
blobs by mark number or to pick off where it left off in a previous
run using a marks file.
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Ramkumar Ramachandra @ 2011-01-20 4:50 UTC (permalink / raw)
To: Jonathan Nieder, Junio C Hamano; +Cc: Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110119214827.GA31733@burratino>
Hi,
Jonathan Nieder writes:
> Junio C Hamano wrote:
> > Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
> >> Introduce a new command-line option --inline-blobs that always inlines
> >> blobs instead of referring to them via marks or their original SHA-1
> >> hash.
> [...]
> > Hmm, this smells somewhat fishy.
> >
> > Wasn't G-F-I designed to be a common stream format for other SCMs to
> > generate streams, so that importers and exporters can be written once for
> > each SCM to interoperate?
>
> Here is one way to sell it:
>
> With the inline blobs feature, fast-import backends have to
> maintain less state. Using it should speed up exporting.
>
> This is made optional because ...
>
> I haven't thought through whether it ought to be optional or measured
> the effect on import performance.
It simplifies other fast-import backends greatly, because persisting
blobs can be complicated and expensive. I was thinking of making
svn-fe support both inlined blobs, and blobs referenced by marks. When
it's possible to be cheap by optionally having inlined blobs, why not
optionally have them? The filter we develop later can be used for
older fast-import streams that don't have inlined blobs.
On a related note, does it make sense to version our fast-import
stream format? It's certainly going to keep evolving with time, and we
need backward compatibility.
> A separate question is what an svn fast-import backend should do with
> all those blobs that are not ready to be written to dump. As a hack
> while prototyping, one can rely on the "current" fast-export output,
> even though that is not flexible or futureproof. Longer term, the
> folllowing sounds very interesting
Good point. The functionality to persist blobs that are refenced by
marks probably shouldn't be in svn-fe at all.
> > Just thinking aloud, but is it possible to write a filter that converts an
> > arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> > referenced blobs by inlining all the blobs?
>
> to avoid complexity in the svn fast-import backend itself.
> (Complicating detail: such a filter would presumably take responsibility
> for --export-marks, so it might want a way to retrieve commit marks
> from its downstream.)
This filter will need to persist every blob for the entire lifetime of
the program. We can't possibly do it in-memory, so we have to find
some way to persist them on-disk and retrieve them very
quickly. Jonathan suggested using something like ToyoCabinet earlier-
I'll start working and see what I come up with.
-- Ram
^ permalink raw reply
* Re: Opinions on my GIT model
From: Ramkumar Ramachandra @ 2011-01-20 4:33 UTC (permalink / raw)
To: julia; +Cc: git
In-Reply-To: <1295465635148-5941048.post@n2.nabble.com>
Hi Julia,
julia writes:
> Working on a GIT model for my projects.
>
> 1. Three main repositories, bare public repo, maintainer repo, developer
> repo
> 2. Developer1 clones the public repo and makes feature1 branch, updates,
> commits changes and pulls/pushes.
> 3. Developer2 on their local repo does the same thing and pushes updates.
> 4. Maintainer get the green light to rebase feature1 branch with master -
> they pull the whole repo, rebase the feature1 branch with master and then
> push feature1.
> 5. Developer1 pulls feature1 brach again and continues to work, does a
> pull/push to feature1 on public repo.
Having a mainline + feature branches is a very common development
model.
> Now, main question is - given that in step 4 maintainer rebase the feature
> branch with master then pushed, he is committing a cardinal sin by rebasing
> a branch that has already been pushed to the public repo, so if anyone has
> made any changes based on the commits originally pushed that now have been
> rebased - developer who tries to push those changes will have issues.
>
> Will these be solved by executing of a pull?
In many projects, including git.git itself, master's history is never
overwritten. Feature branches are merged into `pu`, then into `next`,
and finally graduate to `master`. I suppose it's a matter of
convinience- you should have atleast one stable branch (ie. `master`)
so that developers know what to base their work on.
git-pull.sh is a porcelain-level helper that executes a fetch and
performs a kind of merge/ rebase depending on the situation and
command-line flags. I'd encourage you to read the manpage and shell
script itself and see what all these options are, and how they work.
Finally, I think the merge operation is what you're looking
for. Please read git-merge(1).
-- Ram
^ permalink raw reply
* Re: Noob question regarding git push
From: Alex Budovski @ 2011-01-20 2:35 UTC (permalink / raw)
To: Harry Johnson; +Cc: Sverre Rabbelier, git
In-Reply-To: <AANLkTins5KrYmy6gBJXphEMhcgCEDYcbEGpb7nyU-P=m@mail.gmail.com>
On Thu, Jan 20, 2011 at 10:10 AM, Harry Johnson <hjohnson@viasic.com> wrote:
> Thanks! It was in that faq. So it sounds like I just need to do a git
> reset --hard before doing the builds... This shouldn't be a problem
> since that working tree should never have any local changes. It is
> just a snapshot to be used for builds. However, it does sound like
> maybe I should look into a bare repo and then the build repo could
> just be a clone of that.
The central repo itself should be bare.
^ permalink raw reply
* Re: Noob question regarding git push
From: Harry Johnson @ 2011-01-19 23:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <AANLkTik5QOoWNjUP8LvRE=AmiAtmchc8NND9aKDe2svR@mail.gmail.com>
Thanks! It was in that faq. So it sounds like I just need to do a git
reset --hard before doing the builds... This shouldn't be a problem
since that working tree should never have any local changes. It is
just a snapshot to be used for builds. However, it does sound like
maybe I should look into a bare repo and then the build repo could
just be a clone of that.
Thanks again!
-Harry
On Wed, Jan 19, 2011 at 5:50 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Wed, Jan 19, 2011 at 23:30, Harry Johnson <hjohnson@viasic.com> wrote:
>> What's the proper technique for making sure you see the actual changes
>> that were pushed to a repo?
>
> I think this is the FAQ you want:
>
> https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F
>
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Noob question regarding git push
From: Junio C Hamano @ 2011-01-19 22:56 UTC (permalink / raw)
To: Harry Johnson; +Cc: git
In-Reply-To: <AANLkTi=X8PURGSX5ODHpXACUWuA0oioTkeNEmRVnkx1D@mail.gmail.com>
Harry Johnson <hjohnson@viasic.com> writes:
> This seems to work and I can see my changes when doing a git log from
> the build repo. However, the actual working files have not been
> updated nor can I figure out any way to get them updated.
This is a FAQ, isn't it?
https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F
^ permalink raw reply
* Re: Noob question regarding git push
From: Sverre Rabbelier @ 2011-01-19 22:50 UTC (permalink / raw)
To: Harry Johnson; +Cc: git
In-Reply-To: <AANLkTi=X8PURGSX5ODHpXACUWuA0oioTkeNEmRVnkx1D@mail.gmail.com>
Heya,
On Wed, Jan 19, 2011 at 23:30, Harry Johnson <hjohnson@viasic.com> wrote:
> What's the proper technique for making sure you see the actual changes
> that were pushed to a repo?
I think this is the FAQ you want:
https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Noob question regarding git push
From: Harry Johnson @ 2011-01-19 22:30 UTC (permalink / raw)
To: git
Hi All,
So I have a central build repo from which we perform nightly builds.
Then my development repo is a clone of the build repo. The idea is
that after I am convinced that my changes in my development repo are
stable enough I push them to the build repo using git push.
This seems to work and I can see my changes when doing a git log from
the build repo. However, the actual working files have not been
updated nor can I figure out any way to get them updated. For instance
I have tried deleting one of the files that should be changed and then
doing a git checkout <file>. The changes are still not present. I have
tried doing a git reset --hard HEAD. The file still doesn't contain
the changes. I have even tried checking out a different branch in the
build repo and then re-checking out the master that should have those
changes. Still nothing.
What's the proper technique for making sure you see the actual changes
that were pushed to a repo?
This is debian lenny with git version 1.5.6.5.
TIA,
-Harry
^ permalink raw reply
* Re: pushing to a remote branch that one does not own
From: iani @ 2011-01-19 22:28 UTC (permalink / raw)
To: git
In-Reply-To: <4D373AA2.7000501@seznam.cz>
Thanks a lot for the prompt answer. Following your advice I read the progit
online chapter about branches and it explained to me about git branch lilt
origin/lilt as Maaartin explains. So I am testing it now.
Thanks
Iannis Z.
--
View this message in context: http://git.661346.n2.nabble.com/pushing-to-a-remote-branch-that-one-does-not-own-tp5940751p5941621.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Jonathan Nieder @ 2011-01-19 21:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <7vtyh4smer.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> Introduce a new command-line option --inline-blobs that always inlines
>> blobs instead of referring to them via marks or their original SHA-1
>> hash.
[...]
> Hmm, this smells somewhat fishy.
>
> Wasn't G-F-I designed to be a common stream format for other SCMs to
> generate streams, so that importers and exporters can be written once for
> each SCM to interoperate?
Here is one way to sell it:
With the inline blobs feature, fast-import backends have to
maintain less state. Using it should speed up exporting.
This is made optional because ...
I haven't thought through whether it ought to be optional or measured
the effect on import performance.
A separate question is what an svn fast-import backend should do with
all those blobs that are not ready to be written to dump. As a hack
while prototyping, one can rely on the "current" fast-export output,
even though that is not flexible or futureproof. Longer term, the
folllowing sounds very interesting
> Just thinking aloud, but is it possible to write a filter that converts an
> arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
> referenced blobs by inlining all the blobs?
to avoid complexity in the svn fast-import backend itself.
(Complicating detail: such a filter would presumably take responsibility
for --export-marks, so it might want a way to retrieve commit marks
from its downstream.)
^ permalink raw reply
* [PATCH] git-gui: update russian translation
From: Alex Riesen @ 2011-01-19 21:01 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Pat Thoyts, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov
In-Reply-To: <20110119104856.GA5473@dpotapov.dyndns.org>
Improve the translation of warning given by mergetool when staging files with
conflict markers.
Suggested-by: Alexey Shumkin <zapped@mail.ru>
Tipping-vote-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
On Wed, 19 Jan 2011 13:48:56 +0300, Dmitry Potapov wrote:
> On Wed, Jan 19, 2011 at 08:36:32AM +0000, Alexey Shumkin wrote:
>> So, I agree sentence must rephrased but supposition must be retained.
>> Something like "Файл %s, похоже, содержит неразрешенные конфликты"
>
> I like this one.
So be it.
Please, apply on top of the previously sent patches.
po/ru.po | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/po/ru.po b/po/ru.po
index 7071a8c..30f4b77 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -1926,7 +1926,7 @@ msgstr ""
#, tcl-format
msgid "File %s seems to have unresolved conflicts, still stage?"
msgstr ""
-"Файл %s кажется содержит необработанные конфликты. Продолжить подготовку к "
+"Файл %s, похоже, содержит необработанные конфликты. Продолжить подготовку к "
"сохранению?"
#: lib/mergetool.tcl:60
--
1.7.4.rc2.25.g62eb
^ permalink raw reply related
* checkout to other directory (Re: [PATCH 3/3] setup: always honor GIT_WORK_TREE and core.worktree)
From: Jonathan Nieder @ 2011-01-19 20:52 UTC (permalink / raw)
To: Maaartin; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <4D374B04.80500@seznam.cz>
Maaartin wrote:
> Actually I did mostly something like
>
> git --work-tree /tmp/somewhere checkout somebranch -- .
> && winmerge . /tmp/somewhere
>
> at root of my normal work tree as a poor man's replacement for
>
> git difftool somebranch
>
> This is probably no good idea as it mixes up the index.
Right. I think the simplest (and usual) method is something like
rm -fr /tmp/somewhere &&
mkdir -p /tmp/somewhere &&
git archive somebranch | (cd /tmp/somewhere && tar -xf -)
But suppose that the tracked tree is very big, so that re-creating
/tmp/somewhere each time is expensive. Then you can do
(
GIT_DIR=$(pwd)/.git &&
GIT_INDEX_FILE=$(pwd)/.git/somewhere-index &&
export GIT_DIR GIT_INDEX_FILE &&
cd /tmp/somewhere &&
git update-index --refresh -q &&
git read-tree --reset -m -u somebranch
)
The state of /tmp/somewhere is remembered in the somewhere-index file.
In practice, I tend to use something closer to the following:
sh /usr/share/doc/git/contrib/git-new-workdir repo /tmp/somewhere &&
(
cd /tmp/somewhere &&
git checkout somebranch^0
)
See [1] for caveats and future directions.
[1] http://thread.gmane.org/gmane.comp.version-control.git/150559
^ permalink raw reply
* Re: [PATCH 3/3] setup: always honor GIT_WORK_TREE and core.worktree
From: Maaartin @ 2011-01-19 20:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7v4o94u26f.fsf@alter.siamese.dyndns.org>
On 11-01-19 20:24, Junio C Hamano wrote:
> Maaartin <grajcar1@seznam.cz> writes:
>
>> On 11-01-19 13:42, Jonathan Nieder wrote:
>>> Unfortunately the existence of GIT_WORK_TREE makes it tempting to
>>> use without setting GIT_DIR.
>>
>> Maybe I'm asking nonsense, but why should I always use both? On the
>> command line, I either cd to my (alternate) working tree and use GIT_DIR
>> only or the other way round.
>
> As long as you were at the root level of these two sets of "working trees",
> you don't need GIT_WORK_TREE at all.
Actually I did mostly something like
git --work-tree /tmp/somewhere checkout somebranch -- .
&& winmerge . /tmp/somewhere
at root of my normal work tree as a poor man's replacement for
git difftool somebranch
This is probably no good idea as it mixes up the index. Sorry for
misusing this thread, but a side question: Should I specify
GIT_INDEX_FILE or is there a better way?
Btw., I see that GIT_INDEX_FILE is relative to the work tree instead of
to the git dir. I find it strange as it's normally a part of the git dir.
> We originally had only GIT_DIR and people who wanted to use a working tree
> without an embedded .git (hence having to use GIT_DIR) complained that
> they cannot work from subdirectories while cd'ing around, because you
> declare that you are at the root of your working tree by using GIT_DIR
> (naturally, there is no discovery of .git so we won't know where the root
> is). GIT_WORK_TREE was added to augment the mechanism to allow them to
> specify where their root is, so that they can set both and then chdir
> around inside their working tree.
That's nice.
^ permalink raw reply
* Re: [PATCH 3/3] setup: always honor GIT_WORK_TREE and core.worktree
From: Junio C Hamano @ 2011-01-19 20:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nguyen Thai Ngoc Duy, Junio C Hamano, git, Maaartin
In-Reply-To: <20110119193116.GB30618@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Maaartin wrote:
>> On 11-01-19 13:42, Jonathan Nieder wrote:
>
>>> Unfortunately the existence of GIT_WORK_TREE makes it tempting to
>>> use without setting GIT_DIR.
>>
>> Maybe I'm asking nonsense, but why should I always use both?
>
> That is, why do we want to discourage setting the work tree without
> GIT_DIR in the first place?
I read that one quite differently. Maaartin was always at the root level
and did not need GIT_WORK_TREE, and in such a case there is no need to use
both. Only GIT_DIR is needed.
This is a tangent, because I just said what Maaartin said is
irrelevant to the question "Why do I have to set GIT_DIR when I want
to set GIT_WORK_TREE?", which is what you are discussing, but I
suspect Maaartin was not getting the correct output from diff commands
by having two sets of "working tree" looking files, chdir'ing to their
root level and having a single GIT_DIR, and was not noticing it. It
should _not_ work: think "index".
The answer to your question might be your question itself, though.
Having said that, thanks for a nice summary.
> 1. Previously there was some confusion about what path the worktree
> is relative to. Now setup_explicit_git_dir makes it clear:
> + GIT_WORK_TREE and --work-tree are relative to the original cwd;
> + the "[core] worktree" setting is relative to the gitdir.
Good. I earlier said that relative GIT_WORK_TREE does not make much
sense, but I wasn't (and I am not) opposed to the above definition. It is
just that
GIT_DIR=/some/where; export GIT_DIR
cd /some/other/place
GIT_WORK_TREE=. git reset --hard
cd onelevel
edit edit edit
GIT_WORK_TREE=.. git add file
cd twolevels
edit edit edit
GIT_WORK_TREE=../.. git add file
...
would be a much more cumbersome thing to do compared to:
GIT_WORK_TREE=/some/other/place; export GIT_WORK_TREE
cd $(GIT_WORK_TREE)
git reset --hard
cd onelevel
edit edit edit
git add file
cd twolevels
edit edit edit
git add file
...
> 5. The interaction with core.bare and implicit bareness are not
> obvious. Clearly core.bare should conflict with core.worktree,
> but can GIT_WORK_TREE override that? Maybe
> check_repository_format_gently is the right place for this check
> (rather than the setup procedure).
IIRC, we on purpose added support to allow GIT_WORK_TREE to tentatively
lift bareness of a repository so that people can
cd /var/tmp
GIT_WORK_TREE=. git --git-dir=/srv/git/jgit.git checkout -f
to get a snapshot easily.
> (1) and (2) have been resolved by your work (nice!), (3) seems like
> a case of "don't do that, then", and (4) out to error out in
> setup_nongit (though my patch doesn't take care of that). Given an
> answer to (5) we could wholeheartedly and consistently support
> worktree with implicit gitdir, as a new feature.
As long as we really can support it _consistently_, I wouldn't see a big
problem in resurrecting the historical accident as a feature. You earlier
said gitolite also misuses the interface, but does the usage pattern it
has the same as the one in the debian script you had trouble with, and do
they expect the same behaviour?
^ permalink raw reply
* Re: pushing to a remote branch that one does not own
From: Alexey Shumkin @ 2011-01-19 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <1295461011273-5940751.post@n2.nabble.com>
> Am I strictly limited to committing only on the master / origin/master
> branched, and forced to make a new branch for every branch that I cloned
> from the remote repo, or is there a way of making the heads of the remote
> branches visible as local too?
>
> Thanks,
>
> Iannis Zannos
>
Maybe you should read "Pro Git" book chapter 3 "Git Branching"
http://progit.org/book/ch3-0.html
(and look forward for chapter 3.5 "Remote Branches")?
^ permalink raw reply
* Re: [PATCH 4/5] fast-export: Introduce --inline-blobs
From: Junio C Hamano @ 2011-01-19 19:50 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <1295415899-1192-5-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Introduce a new command-line option --inline-blobs that always inlines
> blobs instead of referring to them via marks or their original SHA-1
> hash.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> Documentation/git-fast-export.txt | 5 +++++
> builtin/fast-export.c | 23 +++++++++++++++++++++--
> 2 files changed, 26 insertions(+), 2 deletions(-)
Hmm, this smells somewhat fishy.
Wasn't G-F-I designed to be a common stream format for other SCMs to
generate streams, so that importers and exporters can be written once for
each SCM to interoperate?
This patch will allow you to write an importer that can only take a stream
with inlined blobs without any references to previous occurrences, but if
the exporter for an SCM that you are trying to interoperate with does not
support --inline-blobs, you are screwed.
What is the problem you are really trying to solve? If it is "it is
cumbersome to keep track of blob references", wouldn't it be nicer to
instead make it easier for importers to support referenced blobs?
Just thinking aloud, but is it possible to write a filter that converts an
arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
referenced blobs by inlining all the blobs? Then other people do not have
to implement --inline-blobs to their own exporter.
If that is not possible, should/can we do something to at least allow
people to check if an existing stream is compatible with an importer that
cannot take referenced blobs without actually trying to run import (and
see it fail)? Do we need a way to encourage people to add --inline-blobs
support to their exporters? I suspect this series leads to make G-F-I
less useful by fragmenting the compatible subset of stream formats without
such effort, no?
^ permalink raw reply
* [PATCH 3/3] gitk: Allow displaying time zones from author and commit timestamps
From: Anders Kaseorg @ 2011-01-19 19:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <alpine.DEB.2.02.1101191445130.23868@dr-wily.mit.edu>
Now gitk can be configured to display author and commit dates in their
original timezone, by putting %z into datetimeformat in ~/.gitk.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
gitk | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 5c6058a..a072593 100755
--- a/gitk
+++ b/gitk
@@ -11018,7 +11018,18 @@ proc prefsok {} {
proc formatdate {d} {
global datetimeformat
if {$d ne {}} {
- set d [clock format [lindex $d 0] -format $datetimeformat]
+ if {[string match {*%[zZ]*} $datetimeformat]} {
+ if {[catch {set d [clock format [lindex $d 0] -timezone [lindex $d 1] -format $datetimeformat]}]} {
+ # Tcl < 8.5 does not support -timezone.
+ global env
+ set zone [lindex $d 1]
+ set env(TZ) "IDK[string range $zone 0 2]:[string range $zone 3 end]"
+ set d [clock format [lindex $d 0] -format $datetimeformat]
+ unset env(TZ)
+ }
+ } else {
+ set d [clock format [lindex $d 0] -format $datetimeformat]
+ }
}
return $d
}
--
1.7.4.rc1
^ 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