* 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
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 11:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20071127020842.GN14735@spearce.org>
Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > This program dumps (parts of) a git repository in the format that
> > fast-import understands.
> ...
> > +-------------------------------------------------------------------
> > +$ git fast-export --all | (cd /empty/repository && git fast-import)
> > +-------------------------------------------------------------------
> > +
> > +This will export the whole repository and import it into the existing
> > +empty repository. Except for reencoding commits that are not in
> > +UTF-8, it would be a one-to-one mirror.
>
> WTF?
>
> Why are you reencoding the commits on output in fast-export? Why aren't
> you dumping them raw to the stream? fast-import takes them raw. Oh, it
> doesn't have a way to set the encoding header. DOH.
Not only that... FTFD:
~ Commit messages are free-form and are not interpreted by Git.
~ Currently they must be encoded in UTF-8, as fast-import does not permit
~ other encodings to be specified.
So the documentation stated very much that I _had_ to do it that way.
> I think this should be prefixed by fast-import patch to teach it
> something like "encoding N" as a subcommand of commit, so that you can
> feed data in a non UTF-8 encoding and get it to include the proper
> encoding header in the commit object it creates. That way a pipeline
> like the above really does create a duplicate repository, with the same
> commit SHA-1s, even if the commits weren't in UTF-8.
IMHO it's not worth that hassle. People who want to use fast-import
usually want something fast which works, and not bother with specifying
encodings.
Further, if you go down that road, some people will want to be able to say
"that commit is KOI-8, this one is UTF-8, and the third is encoded in
pre-Christian Tibetan runes."
But maybe I am wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 11:30 UTC (permalink / raw)
To: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
gapon 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).
There isn't any bug tracker for git. Use git mailing list for bug
reports and feature requests.
> 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
Do not push into checked out branch!
> - 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
Perhaps there should. There was some idea and even preliminary
implementation of BASE check, but IIRC it was deemed too complicated,
and encouraging wrong workflow.
Besides, even with the check, pushing into checked out branch can quite
easily lead either to loosing (or at least vanishing) some history,
or problems with pushing.
> * 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
IIRC we strongly discourage in documentation to push into checked out
branch. Either use bare repository for communication (it allows for
example for got for "ideal patch series" by rewriting history _before
publishing (pushing)_ and for communication with more than one
chosen developer), or push into _remotes_, not into heads.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 11:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <20071127101614.GB26072@diana.vm.bytemark.co.uk>
Hi,
On Tue, 27 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote:
>
> > On Sun, 25 Nov 2007, Karl Hasselstr?m wrote:
> >
> > > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:
> > >
> > > > I have been considering creating a "git-gui daemon" process that
> > > > links to libgit.a and can be driven bidirectionally through its
> > > > stdin/stdout. Based on git-fast-export, sorta. But I haven't even
> > > > started it...
> > > >
> > > > But the idea is sort of what Han-Wen wants. Why should I fork
> > > > rev-parse to get a ref value? Or update-ref to change one?
> > >
> > > Obviously, something like this would be very valuable for StGit as
> > > well.
> >
> > Could you be a little more specific _what_ you want to do, and _how_
> > this could be done with fast-export | fast-import?
>
> Currently, a single StGit command can result in quite a few invocations
> of git-cat-file, for example, each of which forks off a new process. If
> it could start just one daemon such as Shawn proposed, and feed it
> simple questions and commands about blobs, trees, commits, and refs,
> that would probably be quite a lot faster.
>
> From what I understand, this is not something that would fit a
> fast-export | fast-import pipeline. Which is why I didn't take the time
> to elaborate on (or indeed find out) exactly which commands StGit would
> like such a daemon to support.
>
> By the way: one command one _would_ likely want in the daemon is "list
> modified files". Being long-lived (not when driven by StGit, perhaps,
> but definitely when driven by git-gui or qgit), the daemon would be able
> to use inotify for that.
Ah, so you would like something like "git --interactive"? This is indeed
a completely different scope than the fast-export thingie, which is meant
as kind of a mysqldump tool. Indeed, you could use it even as a (kind of
a) stash of the repo instead of the working tree.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Alex Riesen @ 2007-11-27 11:21 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
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