* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-27 14:29 UTC (permalink / raw)
To: Johannes Schindelin
Cc: らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711271109130.27959@racer.site>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1280 bytes --]
On Tue, 27 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Nov 2007, しらいしななこ wrote:
>
> > Was it coded poorly, buggy or were there some other issues?
>
> It is very well possible that it was coded poorly ;-)
>
> The main reason, I believe, was that some old-timers who know the
> implications said that it would encourage a wrong workflow. One thing
> that could go possibly wrong, for example, is to rebase commits that you
> already published.
Being much more involved in the maintenance of a published Git tree
lately, I must disagree with the "wrong workflow" statement. Until the
stuff I maintain is finally merged upstream, I have to constantly
amend/replace/fold/split random commits in my repo to follow the review
cycles involved. yet I have to publish the result to let others base
their work on top of my latest tree. A fetch+rebase is the only option
for those following my tree, and I made it clear that they have to
rebase after a fetch because I constantly rebase commits that I have
already published myself.
And in this case, constant rebasing is a perfectly fine work flow to me.
Otherwise I might just use Git as a glorified tarball downloader and use
quilt on top, but this is somehow not as appealing.
Nicolas
^ permalink raw reply
* Re: Git Screencast ?
From: Patrick Aljord @ 2007-11-27 14:18 UTC (permalink / raw)
To: git list
In-Reply-To: <6b6419750711270602q53e2c51dr7046aca1417c801a@mail.gmail.com>
On Nov 27, 2007 3:02 PM, Patrick Aljord <patcito@gmail.com> wrote:
> > http://jointheconversation.org/railsgit
> >
I think you can just use 'git-init' now no need for git-init-db.
also once you've created your remote bare git rep, you don't need to
use scp, you can just do:
$ git-push --all git://server/remote.git
and to push there automatically:
$ git remote add origin ssh://server/remote.git
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master
$ git fetch
$ git merge master
also for adding new files, rather than doing "git add file1 file2
file3 etc" I just do "git add ." and put in .gitignore all the files
that I don't want to commit but I don't know if that's recommended :)
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Nguyen Thai Ngoc Duy @ 2007-11-27 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711271214230.27959@racer.site>
On Nov 27, 2007 7:16 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Nov 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On Nov 23, 2007 9:31 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > Bundle is very handy for transferring a bunch of commits, but it
> > > > does not (cannot?) hold tags and branches.
> > >
> > > But they can! Nothing prevents you from calling
> > >
> > > git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next
> > >
> > > (At least this is the idea, haven't tested yet).
> >
> > It can store commits and heavy tags, but it won't restore tags to
> > refs/tags or advance branches.
>
> The idea is that you fetch them from the bundle. So something like this
> should do what you want:
>
> git fetch a1.bundle v1.0.0:refs/tags/v1.0.0
>
> Note that the automatic tag handling of git fetch kicks in with bundles
> just like with other fetch URLs (Unassuming Repository Locators).
Yes, you are right. Man, if I knew I could pass a bundle to git-fetch,
my life would have been much easier :(
--
Duy
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Nguyen Thai Ngoc Duy @ 2007-11-27 14:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711121224430.4362@racer.site>
On Nov 12, 2007 7:31 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On Nov 12, 2007 6:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > But what about setup_git_directory_gently()? If the working tree is
> > > overridden by the config, this function is still bogus, right?
> >
> > Hmm.. thinking a little bit more. I guess you're right because
> > GIT_WORK_TREE takes precedence over core.worktree. Maybe some more bits
> > for check_repository_format_version(). Tough decision because, from the
> > value of inside_work_tree, we don't know if we can safely skip
> > overriding inside_work_tree.
>
> I was thinking about adding check_repository_format_version() and a check
> for inside_work_tree < 0 with obvious handling in two places, probably as
> a function: first, when we have a gitdirenv but no work_tree_env, and
> second, at the end of _gently() when we found a git dir but only if
> work_tree_env was not set.
>
> > > As far as I see, setup_git_directory_gently() only works correctly
> > > when core.worktree is _not_ set, unless GIT_WORK_TREE is set (which is
> > > supposed to override the config setting). Note: I treat GIT_WORK_TREE
> > > the same as --work-tree, since at that time they are identical.
> > >
> > > Maybe the config stuff has to move into _gently()?
> >
> > Well, it could be a bit more complicated because you need to know
> > GIT_DIR first before reading config. I'd rather not move as _gently()
> > is complicated already.
>
> AFAICT it is not a question of complexity, but of correctness. Wouldn't
> you agree that the prefix _gently() returns is wrong if we don't fix it?
>
> Besides, it might be needed anyway if we are serious about the version
> check. This check, however, would have to be done _whenever_ we found a
> git directory, not only when work_tree_env is NULL.
Question time. setup_git_directory_gently() can be happy even if there
is no repository. Now if we move version check into setup_..._gently
and it finds git program is too old to handle the repository, what
would we do? die() like in check_repository_format() or tell the
caller there is no repository?
--
Duy
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Andreas Ericsson @ 2007-11-27 14:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261417580.9605@xanadu.home>
Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, David Kastrup wrote:
>
>> Get rid of plumbing at the command line level.
>
> We can't get rid of plumbing. It is part of Git probably forever and is
> really really convenient for scripting in any language you want.
>
> The only valid argument IMHO is the way too large number of Git commands
> directly available from the cmdline.
>
> The solution: make purely plumbing commands _not_ directly available
> from the command line. Instead, they can be available through 'git
> lowlevel <blah>' instead of 'git <blah>' and only 'git lowlevel' would
> stand in your shell default path.
>
> Such a scheme can be implemented in parallel with the current one for a
> release while the direct plumbing commands are deprecated in order to
> give script authors a transition period to fix their code.
>
The "git-cmd" form of writing commands was deemed obsolete round about
the time git.sh was rewritten in C. There's just no reason for it
anymore.
It's unfortunate that git-sh-setup makes it equally valid for scripts to
use either form, as we can never get rid of the dashed form when so many
scripts in the core distribution uses it.
Ah well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git bug/feature request
From: gapon @ 2007-11-27 14:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Benoit Sigoure, git
In-Reply-To: <200711271431.21516.jnareb@gmail.com>
Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
> Dnia wtorek 27. listopada 2007, gapon napisał(a):
> > Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
> >> gapon wrote:
> >>> bzr:
> >>> while pushing, bzr tries to merge into the current working copy (of A)
> >>> -> all changes are applied or conflicts occure
> >>
> >> That's wrong, wrong, WRONG! What to do in the case of conflicts?
> >> Whan you pull, you can resolve them, as they are on your local side,
> >> but when you push you cannot do that.
> >
> > i agree - i didn't say that it's correct behaviour - i just said that i
> > like it more than git's one
>
> I think it is just wrong and it is hardly any other be worse.
> By the way, don't current git _refuse_ to update checked out branch?
what do you mean exactly? i will try it
>
> >>> hg:
> >>> while pushing, neither merge nor info message, but new head (branch) is
> >>> created in repo A - so then in A you can commit your changes but it's
> >>> different head (repo A has more heads, use hg heads to list them)
>
> [...]
>
> >> You can do the same with git, but you have to specify new branch name
> >> in repo A, or just configure remote in repo B.
> >
> > how can i do it in repo A? i know how to configure repo B but i didn't
> > know that i can do it for repo B (or better for all "B" repos)
>
> git-clone sets up repo B (the clone) for one direction of transfer,
> from repo A (cloned repo) to repo B (the clone). If you want to push
> to repo A, you should configure repo B to do so.
>
> See also comments below.
>
> >> BTW. how do you want for user A (which might be not at terminal, or
> >> might be not logged in, or might use some application using terminal, or
> >> might use multiple [virtual] terminals, or...) to be informed?
> >
> > quite easily i would say - while doing git status or git commit or so -
> > it doesn't matter if one uses terminal or gui - just let user know that
> > something has changed in his repo
>
> There was an idea, and even preliminary implementation in 'pu' branch
> (proposed updates) to have BASE extension in the index (or in refs,
> I don't remember exactly: search the archives), and check when committing
> if for example push didn't change the repository, didin't advance current
> checked out branch under our feet so to say. This allowed for the behavior
> you want.
>
> It was abandoned, for the following reasons as far as I know.
>
> First, there are legitimate situations, created by current user, where
> branch (HEAD) changes: reset, amend, checkout -m, etc. It would be hard
> to avoid annoing false positives (false alarms).
>
> Second, it was complicated to do correctly, as it affected quite a bit
> of git codebase.
>
> Third, it encourages a wrong (CVS braindamage inspired) workflow. The last
> thing you want when committing changes is to have to resolve some
> conflicts, and/or check if [automatic] conflict resolution is correct.
> Blind merging is a bad, bad idea.
>
> > as i wrote earlier - it's confusing (at least for me) that git marks any
> > files as changed (i haven't changed any file) and more, it adds them to
> > the index
>
> You are welcome to ressurect BASE extension to index file :-)
jakub, thanks for explanation - now it's clear that it's not easy to handle
such case... unfortunately
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-27 13:54 UTC (permalink / raw)
To: Andreas Ericsson
Cc: しらいしななこ,
Jakub Narebski, git
In-Reply-To: <474C1F80.5060404@op5.se>
Hi,
On Tue, 27 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > One thing that could go possibly wrong, for example, is to rebase
> > commits that you already published.
>
> For the vast majority of git users, that's a non-issue as "published" is
> usually defined as "pushed to the publicly advertised watering hole".
No. This is only the "vast majority of git users told by their peers to
use a central repository".
Just because you use git like cvs does not mean that you "use git".
> Yes, I'm aware that git is distributed. That doesn't mean that it's not
> convenient to have one single place where all code meant to be released
> eventually ends up.
It may be convenient for you. I do not like it. Yes, I even made the
mistake with msysGit. In the end, it would have been much more
intelligent to set up a repository which others would have had to fork
from.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: gapon @ 2007-11-27 13:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0711270503s7e69be3bn151cfa58b8067f35@mail.gmail.com>
Dne úterý 27 listopadu 2007 Alex Riesen napsal(a):
> On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > as i wrote in my first email - i know that this is not "correct" scenario
> > (i don't and won't use it anywhere) - but the git's behaviour is in such
> > case confusing, at least for me
> > just for clarification - my email wasn't about how to push or create
> > shared repository - it was just about what i have discovered while
> > playing with different scms
>
> Well... It is known problem, for one. That user B of yours, did he just
> cloned user A's repo?
yes, i can paste here all the scenario step by step if you want
>
> What I suspect is a change in how git-clone setups the cloned repo
> could have taken care of it. We could either setup push-configuration
> so that it just does not work (and let user change to his preference),
> or somehow figure out where the pushed references can safely land
> and put that in the cloned repo configuration (that is "SOMEHOW",
> I afraid. Absolutely no idea what could that be).
hard to say what to do, what is correct - now i would say that i like hg
behaviour the most - but i can be wrong of course; the only purpose of this
discussion is that i have found out (by accident ;) "weird" behaviour of git
in such situation - and because git is definitely my most favorite scm i
wanted to report bug/feature/whatever
thanks for all your comments guys
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-27 13:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ,
Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711271109130.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Nov 2007, しらいしななこ wrote:
>
>> Quoting Andreas Ericsson <ae@op5.se>:
>>
>>> "git pull --rebase" already has an implementation. Dscho cooked one up
>>> which I've been using since then. It works nicely.
>> What is the reason that the option was not added to the official git?
>> Was it coded poorly, buggy or were there some other issues?
>
> It is very well possible that it was coded poorly ;-)
>
> The main reason, I believe, was that some old-timers who know the
> implications said that it would encourage a wrong workflow.
If by "wrong", those old-timers meant "a workflow not commonly used
in a published one-pushes-many-pulls repository", I certainly agree.
> One thing
> that could go possibly wrong, for example, is to rebase commits that you
> already published.
>
For the vast majority of git users, that's a non-issue as "published" is
usually defined as "pushed to the publicly advertised watering hole".
Yes, I'm aware that git is distributed. That doesn't mean that it's not
convenient to have one single place where all code meant to be released
eventually ends up.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 13:38 UTC (permalink / raw)
To: gapon; +Cc: Benoit Sigoure, git
In-Reply-To: <200711271431.21516.jnareb@gmail.com>
Jakub Narebski wrote:
> git-clone sets up repo B (the clone) for one direction of transfer,
> from repo A (cloned repo) to repo B (the clone). If you want to push
> to repo A, you should configure repo B to do so.
>
> See also comments below.
What I forgot to add that git encourages "with integrator" workflows:
either send requests to pull to project maintainer, or send patches
(which allow peer review of them) to maintainer, perhaps via public
project mailing list.
You can do "centralized repository" or "peer to peer" aka "star
topology" workflows, but it is not optimized for those workflows;
you have to work a bit harder.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 13:31 UTC (permalink / raw)
To: gapon; +Cc: Benoit Sigoure, git
In-Reply-To: <200711271350.38468.gapon007@gmail.com>
Dnia wtorek 27. listopada 2007, gapon napisał(a):
> Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
>> gapon wrote:
>>> bzr:
>>> while pushing, bzr tries to merge into the current working copy (of A)
>>> -> all changes are applied or conflicts occure
>>
>> That's wrong, wrong, WRONG! What to do in the case of conflicts?
>> Whan you pull, you can resolve them, as they are on your local side,
>> but when you push you cannot do that.
>
> i agree - i didn't say that it's correct behaviour - i just said that i like
> it more than git's one
I think it is just wrong and it is hardly any other be worse.
By the way, don't current git _refuse_ to update checked out branch?
>>> hg:
>>> while pushing, neither merge nor info message, but new head (branch) is
>>> created in repo A - so then in A you can commit your changes but it's
>>> different head (repo A has more heads, use hg heads to list them)
[...]
>> You can do the same with git, but you have to specify new branch name
>> in repo A, or just configure remote in repo B.
>
> how can i do it in repo A? i know how to configure repo B but i didn't know
> that i can do it for repo B (or better for all "B" repos)
git-clone sets up repo B (the clone) for one direction of transfer,
from repo A (cloned repo) to repo B (the clone). If you want to push
to repo A, you should configure repo B to do so.
See also comments below.
>> BTW. how do you want for user A (which might be not at terminal, or might
>> be not logged in, or might use some application using terminal, or might
>> use multiple [virtual] terminals, or...) to be informed?
>
> quite easily i would say - while doing git status or git commit or so - it
> doesn't matter if one uses terminal or gui - just let user know that
> something has changed in his repo
There was an idea, and even preliminary implementation in 'pu' branch
(proposed updates) to have BASE extension in the index (or in refs,
I don't remember exactly: search the archives), and check when committing
if for example push didn't change the repository, didin't advance current
checked out branch under our feet so to say. This allowed for the behavior
you want.
It was abandoned, for the following reasons as far as I know.
First, there are legitimate situations, created by current user, where
branch (HEAD) changes: reset, amend, checkout -m, etc. It would be hard
to avoid annoing false positives (false alarms).
Second, it was complicated to do correctly, as it affected quite a bit
of git codebase.
Third, it encourages a wrong (CVS braindamage inspired) workflow. The last
thing you want when committing changes is to have to resolve some
conflicts, and/or check if [automatic] conflict resolution is correct.
Blind merging is a bad, bad idea.
> as i wrote earlier - it's confusing (at least for me) that git marks any files
> as changed (i haven't changed any file) and more, it adds them to the index
You are welcome to ressurect BASE extension to index file :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Marco Costalba @ 2007-11-27 13:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <figlf6$d48$1@ger.gmane.org>
On Nov 27, 2007 9:45 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> Marco Costalba wrote:
>
> > But...wait...Qt would require...(I'm scared to say!)... that awful,
> > painful, hopeless thing called C++. Probably you didn't mean what you
> > said ;-)
>
> Actually although I like C++, that's not the reason, the reason is that Qt
> is a significantly (IMHO) better toolkit than Tk. It's more cross platform
> and looks a lot nicer. The fact that it's C++ is neither here nor there.
>
Actually there exist a Python bindings for Qt if you prefer.
I was just joking about C++, never meant to start a "language war"
that I personally consider as very very un-useful and very pity.
Marco
^ permalink raw reply
* Re: git bug/feature request
From: Alex Riesen @ 2007-11-27 13:03 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271231.51270.gapon007@gmail.com>
On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> as i wrote in my first email - i know that this is not "correct" scenario (i
> don't and won't use it anywhere) - but the git's behaviour is in such case
> confusing, at least for me
> just for clarification - my email wasn't about how to push or create shared
> repository - it was just about what i have discovered while playing with
> different scms
Well... It is known problem, for one. That user B of yours, did he just cloned
user A's repo?
What I suspect is a change in how git-clone setups the cloned repo
could have taken care of it. We could either setup push-configuration
so that it just does not work (and let user change to his preference),
or somehow figure out where the pushed references can safely land
and put that in the cloned repo configuration (that is "SOMEHOW",
I afraid. Absolutely no idea what could that be).
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Alex Riesen @ 2007-11-27 12:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Kristian Høgsberg
In-Reply-To: <Pine.LNX.4.64.0711271115300.27959@racer.site>
On 27/11/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> [commenting on the patch is a little cumbersome when the mailer does not
> quote it for you...]
Yes, I'm sorry. But being at work I'm extremely lucky to have access
to even gmail (it was blocked for almost a month as a virus source. Of
course it is a virus source! It is a damn mailbox!)
> On Tue, 27 Nov 2007, Alex Riesen wrote:
>
> @@ -550,6 +557,8 @@ static int parse_and_validate_options(int argc, const char *argv[])
> free(enc);
> }
>
> + if (all)
> + cached_only = 0;
>
> My reply> I would rather add another !!cached_only to the existing if().
I'm... Not sure. I'm using it like this:
$ alias gci='git commit --cached'
$ gci
So sometimes I actually want to override --cached, and just so happens
it is always --all case, which seem to be in line with proposals to make
--all default commit behavior.
> @@ -678,7 +688,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> if (!prepare_log_message(index_file, prefix) && !in_merge) {
> - run_status(stdout, index_file, prefix);
> + if (!cached_only)
> + run_status(stdout, index_file, prefix);
>
> My reply> Would it not make more sense to avoid run_status() when no_edit?
Will try it out this evening at home. I suspect you're right :)
^ permalink raw reply
* Re: git bug/feature request
From: gapon @ 2007-11-27 12:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Benoit Sigoure, git
In-Reply-To: <fih0cd$d31$1@ger.gmane.org>
Dne úterý 27 listopadu 2007 Jakub Narebski napsal(a):
> [Cc: git@vger.kernel.org, gapon <gapon007@gmail.com>,
> Benoit Sigoure <tsuna@lrde.epita.fr>]
>
> Could you _please_ do not toppost?
sure, no problem ;)
>
> gapon wrote:
> > Dne úterý 27 listopadu 2007 Benoit Sigoure napsal(a):
> >> On Nov 27, 2007, at 11:27 AM, gapon wrote:
> >> > * yes, i know that this scenario is "incorrect" but... it's
> >> > possible and
> >> > therefore i think it should be somehow handled - i tried a similar
> >> > one with
> >> > hg and bzr and i like their behaviour more
> >>
> >> Would you mind describing the behavior of hg and bzr in this case?
>
> [...]
>
> > bzr:
> > while pushing, bzr tries to merge into the current working copy (of A)
> > -> all changes are applied or conflicts occure
>
> That's wrong, wrong, WRONG! What to do in the case of conflicts?
> Whan you pull, you can resolve them, as they are on your local side,
> but when you push you cannot do that.
i agree - i didn't say that it's correct behaviour - i just said that i like
it more than git's one
>
> > hg:
> > while pushing, neither merge nor info message, but new head (branch) is
> > created in repo A - so then in A you can commit your changes but it's
> > different head (repo A has more heads, use hg heads to list them)
> > btw i filed and enhancement for hg, to let user know that there are more
> > heads in the repo (you have to use hg log or hg heads to discover that
> > someone else has pushed into your repo and hg merge to merge them)
>
> That is also wrong: how do you decide name of new branch then, and
> woundn't this lead to proliferation of branches?
i don't agree that it's wrong - in the hg log all you see is that the commit
from repo B has different parent - that's all
if hg status (or similar) printed some info about this situation it would be
enough i would say - but just my opinion/feeling of course
>
> You can do the same with git, but you have to specify new branch name
> in repo A, or just configure remote in repo B.
how can i do it in repo A? i know how to configure repo B but i didn't know
that i can do it for repo B (or better for all "B" repos)
>
> BTW. how do you want for user A (which might be not at terminal, or might
> be not logged in, or might use some application using terminal, or might
> use multiple [virtual] terminals, or...) to be informed?
quite easily i would say - while doing git status or git commit or so - it
doesn't matter if one uses terminal or gui - just let user know that
something has changed in his repo
as i wrote earlier - it's confusing (at least for me) that git marks any files
as changed (i haven't changed any file) and more, it adds them to the index
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Alex Riesen @ 2007-11-27 12:48 UTC (permalink / raw)
To: Johannes Sixt
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <474C0105.3010908@viscovery.net>
On 27/11/2007, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Alex Riesen schrieb:
> > The option is to enable operation exclusively on the index, without touching
> > working tree. Besides speeding up commit process on performance-challenged
> > platforms it also has to ensure that the index is commited exactly how
> > user sees it.
>
> Huh?
>
> Doesn't git-commit operate only on the index, unless you pass it extra
> arguments?
It doesn't
> What am I missing?
run_status and check for changed files
^ permalink raw reply
* [PATCH] t7003-filter-branch: Fix test of a failing --msg-filter.
From: Johannes Sixt @ 2007-11-27 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Sixt
The test passed for the wrong reason: If the script given to --msg-filter
fails, it is expected that git-filter-branch aborts. But the test forgot
to tell the branch name to rewrite, and so git-filter-branch failed due to
incorrect usage.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t7003-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 2089351..5f60b22 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -114,7 +114,7 @@ test_expect_success 'use index-filter to move into a subdirectory' '
test_expect_success 'stops when msg filter fails' '
old=$(git rev-parse HEAD) &&
- ! git-filter-branch -f --msg-filter false &&
+ ! git-filter-branch -f --msg-filter false HEAD &&
test $old = $(git rev-parse HEAD) &&
rm -rf .git-rewrite
'
--
1.5.3.6.967.ga9b45
^ permalink raw reply related
* Re: QGit: Shrink used memory with custom git log format
From: Marco Costalba @ 2007-11-27 12:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711271045430.27959@racer.site>
On Nov 27, 2007 11:48 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> > > Indeed there is a git-rev-list --stdin option but with different
> > > behaviour from git-diff-tree --stdin and not suitable for this.
> >
> > There was a proposed patch for git-cat-file that would let you run
> > it in a --stdin mode; the git-svn folks wanted this to speed up
> > fetching raw objects from the repository. That may help as you
> > could get commit bodies (in raw format - not reencoded format!)
> > quite efficiently.
>
That would be nice.
> > Otherwise I think what you really want here is a libgit that you can
> > link into your process and that can efficiently inflate an object
> > on demand for you.
I would think libgit is overkilling for this.
You probably would not use libgit to just add a single feature but to
change completely the interface with git because the required work is
heavy both on git side and qgit side (you probably would want to run
the libgit linked part in a separated thread to avoid GUI soft locks
during slow processing, now, because the executed git command is a
different process from qgit, the OS scheduler takes care of this 'for
free').
Marco
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 12:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0711240608w2e5e0812me0e56c1f1a2f8c85@mail.gmail.com>
Hi,
On Sat, 24 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 23, 2007 9:31 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > Bundle is very handy for transferring a bunch of commits, but it
> > > does not (cannot?) hold tags and branches.
> >
> > But they can! Nothing prevents you from calling
> >
> > git bundle create a1.bundle refs/tags/v1.0.0 refs/heads/next
> >
> > (At least this is the idea, haven't tested yet).
>
> It can store commits and heavy tags, but it won't restore tags to
> refs/tags or advance branches.
The idea is that you fetch them from the bundle. So something like this
should do what you want:
git fetch a1.bundle v1.0.0:refs/tags/v1.0.0
Note that the automatic tag handling of git fetch kicks in with bundles
just like with other fetch URLs (Unassuming Repository Locators).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 12:14 UTC (permalink / raw)
To: Junio C Hamano, spearce; +Cc: git
In-Reply-To: <7vsl2sgadf.fsf@gitster.siamese.dyndns.org>
Hi,
[Shawn Cc'ed, since it affects fast-import]
On Mon, 26 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 25 Nov 2007, Junio C Hamano wrote:
> >
> >> I am not sure if abort should be the default.
> >
> > I tried to be conservative.
> >
> >> If a straight dump-restore is made without rewriting, the result will
> >> be identical to the original, right?
> >
> > Yep.
> > ...
> > I agree that for most serious operations sed is not good enough.
>
> My comment was more about the perception from a new user (not a "new git
> user", but a "new fast-export and fast-import user").
>
> When you see a command pair foo-export and foo-import, and it is
> advertised that you can pipe them together, a new user would first try a
> straight dump-restore, and would see the warning even though he did not
> do any editing on the stream.
>
> Huh? Why does a tag signature become invalid because of merely
> exporting and then importing? What is this warning about?
Okay, I did not see that.
> You would explain "yeah in your trial run you did not edit but the
> command pair is to allow you editing the contents in between, and if you
> do that, the object names might change.".
>
> If the default were "straight copy", then the user will not get an
> invalid signature on his trial run, but will get an invalid signature
> when he rewrites the object stream. You would get a message on the list
> like this:
>
> Hello, I tried fast-export piped to fast-import so that I can
> rewrite my repository, but I am getting invalid signature on
> signed tags. It does not seem to happen if I do not edit but
> just use the fast-export output without modification. What am I
> doing wrong?
>
> And that is the time the explanation first becomes useful. IOW, you are
> warning at the wrong place. "It may or may not corrupt the signature, I
> do not know. Because it depends on what you are going to do with my
> output, I cannot know. I am warning you anyway to cover my backside".
>
> I am wondering if fast-import input syntax can be extended to allow
> checking inconsistencies. A command to import a tag could take an
> additional object name and tell it to warn if the name of the tagged
> object (the one sent with "from:%d\n" part) is different from that
> object name. At that point, you know the object was rewritten and the
> signature is invalid, and the choice of warning, stripping or aborting
> becomes a useful thing to have.
Why not check by default? Whenever there is a tag message containing the
magic BEGIN line, it should check and at least warn if it does not
match...
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 11:51 UTC (permalink / raw)
To: git
In-Reply-To: <200711271216.25283.gapon007@gmail.com>
[Cc: git@vger.kernel.org, gapon <gapon007@gmail.com>,
Benoit Sigoure <tsuna@lrde.epita.fr>]
Could you _please_ do not toppost?
gapon wrote:
> Dne úterý 27 listopadu 2007 Benoit Sigoure napsal(a):
>> On Nov 27, 2007, at 11:27 AM, gapon wrote:
>> > * yes, i know that this scenario is "incorrect" but... it's
>> > possible and
>> > therefore i think it should be somehow handled - i tried a similar
>> > one with
>> > hg and bzr and i like their behaviour more
>>
>> Would you mind describing the behavior of hg and bzr in this case?
[...]
>
> bzr:
> while pushing, bzr tries to merge into the current working copy (of A)
> -> all changes are applied or conflicts occure
That's wrong, wrong, WRONG! What to do in the case of conflicts?
Whan you pull, you can resolve them, as they are on your local side,
but when you push you cannot do that.
> hg:
> while pushing, neither merge nor info message, but new head (branch) is
> created in repo A - so then in A you can commit your changes but it's
> different head (repo A has more heads, use hg heads to list them)
> btw i filed and enhancement for hg, to let user know that there are more heads
> in the repo (you have to use hg log or hg heads to discover that someone else
> has pushed into your repo and hg merge to merge them)
That is also wrong: how do you decide name of new branch then, and
woundn't this lead to proliferation of branches?
You can do the same with git, but you have to specify new branch name
in repo A, or just configure remote in repo B.
BTW. how do you want for user A (which might be not at terminal, or might
be not logged in, or might use some application using terminal, or might
use multiple [virtual] terminals, or...) to be informed?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* C# binding, was Re: If you would write git from scratch now, what would you change?
From: Johannes Schindelin @ 2007-11-27 11:47 UTC (permalink / raw)
To: Jakub 'CC-me' Narebski; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <200711270315.56849.jnareb@gmail.com>
Hi,
On Tue, 27 Nov 2007, Jakub Narebski wrote:
> Shawn O. Pearce wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> ... not to mention countless others you would get wrong that you did not
> >> list in the above, as the current git got them right ;-)
> >
> > Indeed.
> >
> > Which is why nobody is looking to rewrite Git from scratch.
> >
> > Except myself and a few other nuts who want a pure Java
> > implementation for Eclipse plugins. :-)
>
> And the project to implement git in C# / Mono (I wonder what is
> the status of those implementations...)
See for yourself. I started listing some plumbings in
http://git.or.cz/gitwiki/Plumbings, but it seems that the homepage points
to a wrong URL for the repo. The correct one is
http://repo.or.cz/w/Widgit.git.
Hth,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Johannes Schindelin @ 2007-11-27 11:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071127015833.GL14735@spearce.org>
Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> Actually I might revisit this XUL concept using an HTTP server and AJAX.
> I could actually link the damn HTTP server against libgit.a (Junio will
> hate me). If the server dies XUL can notice it and simply restart it.
But if you can restart the HTTP server via XUL, you can start other git
programs directly.
What you'd have to do is (urgh) write a wrapper via start_command()
which would recognize that the second process die()d.
All in all, I think if you want to switch from Tcl/Tk to another language
for git-gui, for the sake of attracting more developers, it might be wiser
to go Java than XUL.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Johannes Sixt @ 2007-11-27 11:35 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <81b0412b0711270254i58be4d2fi5021767d99fcb753@mail.gmail.com>
Alex Riesen schrieb:
> The option is to enable operation exclusively on the index, without touching
> working tree. Besides speeding up commit process on performance-challenged
> platforms it also has to ensure that the index is commited exactly how
> user sees it.
Huh?
Doesn't git-commit operate only on the index, unless you pass it extra
arguments?
What am I missing?
-- Hannes
^ permalink raw reply
* Re: git bug/feature request
From: gapon @ 2007-11-27 11:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0711270321q6f70554at177ade878448b9fc@mail.gmail.com>
as i wrote in my first email - i know that this is not "correct" scenario (i
don't and won't use it anywhere) - but the git's behaviour is in such case
confusing, at least for me
just for clarification - my email wasn't about how to push or create shared
repository - it was just about what i have discovered while playing with
different scms
gapon
Dne úterý 27 listopadu 2007 Alex Riesen napsal(a):
> On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > hi all,
> > first of all i don't know if there's a bugzilla or something similar for
> > git - i have found just this email (on http://git.or.cz/ webpage).
> >
> > i have discovered "weird" behaviour of git in this scenario*:
> > - user A is working in repo A
> > - user B clones repo A
> > - user B makes some changes, commits, pushes
> > - user A makes some changes, git status (no info about new commit in his
> > repo from user B but it's probably ok i'd say - but some of my files are
> > marked as changed and already added to index but i haven't changed them
> > - that's confusing, isn't it?)
> > - user A can commit his changes => shouldn't be there any
> > info/message/warning displayed? it would be helpful to have here some
> > info about "foreign commit" in the repo or something like this
>
> If you share a repository with someone else, you better use different
> branches. What's happened is that user B changed the branch the
> user A was working on (strictly speaking, the B-user changed the
> reference A-user used as HEAD at the moment).
>
> Just have the B-user push his/hers changes on something else,
> not the master of the parent repository. For instance, B-user can
> add a "push"-line to his origin remote which redirects its pushes
> somewhere else:
>
> git config remote.origin.push 'refs/heads/*:refs/heads/B-user/*'
>
> Or just use a dedicated shared repo where no one works in.
> See also Documentation/config.txt, and the man page of git-push.
^ 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