* 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: [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: [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: 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: 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 bug/feature request
From: Peter Karlsson @ 2007-11-27 14:35 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
gapon:
> i have discovered "weird" behaviour of git in this scenario*:
Yeah, I have run into it several times myself, and that is being both
user A and B at the same time. The problem seems to be that git allows
you to push into a repository which has a check-out, causing it to
change states in a subtle way. That's just plain broken.
Git should either handle it somehow (perhaps by forcing the push into a
new branch, which the pushee needs name), or just plainly refuse to
push into a repository with a check-out.
I have learned to work around this problem by always pulling between my
repositories, not pulling. I could probably have worked around it by
having a master repository that is bare, but I have found that
difficult because I am tracking an upstream non-Git repository, so to
push and pull changes from that, I need a repository where I can have a
check-out.
> * 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
Yeah. It's even more irritating that recovering from the error state is
difficult as well.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jakub Narebski @ 2007-11-27 14:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Nicolas Pitre, David Kastrup, git
In-Reply-To: <474C259B.1000705@op5.se>
Andreas Ericsson wrote:
> 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.
I think it would be enough to have "git" and perhaps "git-sh-setup"
in PATH, and the rest of git-cmd in EXEC_PATH != PATH.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git bug/feature request
From: David Kastrup @ 2007-11-27 14:38 UTC (permalink / raw)
To: Peter Karlsson; +Cc: gapon, git
In-Reply-To: <Pine.LNX.4.64.0711271531110.1011@ds9.cixit.se>
Peter Karlsson <peter@softwolves.pp.se> writes:
> I have learned to work around this problem by always pulling between
> my repositories, not pulling.
Uhm...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Schindelin @ 2007-11-27 14:46 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0711270612p52ce20eaue39eac1d529c3fd3@mail.gmail.com>
Hi,
On Tue, 27 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> 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?
In the interest of least surprise, die().
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Karl Hasselström @ 2007-11-27 14:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <Pine.LNX.4.64.0711271123360.27959@racer.site>
On 2007-11-27 11:25:47 +0000, Johannes Schindelin wrote:
> Ah, so you would like something like "git --interactive"? This is
> indeed a completely different scope than the fast-export thingie,
Yes. Or rather, I _think_ that's what I want. The only numbers I have
is that StGit makes a number of trivial git calls that right now take
on the order of 10 ms apiece, so the first step in this direction
would be to build a simple prototype just to see what kind of speed-up
one could expect (both in the git calls, and in StGit overall).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH RFC] Move all dashed form git commands to libexecdir
From: Nguyễn Thái Ngọc Duy @ 2007-11-27 15:02 UTC (permalink / raw)
To: git
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
We have talked about it for quite some time now. How about
making it happen? I won't miss dashed form commands much :)
A compromised approach could be keeping porcelain commands
in bindir, only plumbings are moved to libexecdir. That would
be less shock than this.
config.mak.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 11d256e..1db0338 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -11,7 +11,7 @@ TCLTK_PATH = @TCLTK_PATH@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
+gitexecdir = @libexecdir@/git-core/
datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates/
--
1.5.3.GIT
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-27 15:08 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711270917580.9605@xanadu.home>
On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> 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.
Right. But a rebase "merge strategy" doesn't work for those people,
because it's not possible in general for their git to know exactly which
part is their work (which needs to be rebased) and which is your old
work (which should be discarded). Manual inspection is required.
> And in this case, constant rebasing is a perfectly fine work flow to me.
Again, if you have people basing work on top of yours, I think the best
option may really be to add a merge commit on top of each new version of
the series with first parent the new series and second parent the
previous history.
That way the history does have the information necessary to rebase their
work automatically.
--b.
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 15:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <20071127145103.GA30020@diana.vm.bytemark.co.uk>
Hi,
On Tue, 27 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-27 11:25:47 +0000, Johannes Schindelin wrote:
>
> > Ah, so you would like something like "git --interactive"? This is
> > indeed a completely different scope than the fast-export thingie,
>
> Yes. Or rather, I _think_ that's what I want. The only numbers I have is
> that StGit makes a number of trivial git calls that right now take on
> the order of 10 ms apiece, so the first step in this direction would be
> to build a simple prototype just to see what kind of speed-up one could
> expect (both in the git calls, and in StGit overall).
I'd rather see you using libgit-thin's Python binding.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH RFC] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-27 15:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20071127150229.GA14859@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 450 bytes --]
Hi,
On Tue, 27 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/config.mak.in b/config.mak.in
I don't use configure, and don't expect distros to use it either. Maybe
you want to change Makefile first, so that the hard-core "next" followers
test it first? Then, when everything is worked out and deemed to be
stable, Junio can merge it to "master", and we can adjust the rpm spec and
bug packagers to change their setup?
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711271531110.1011@ds9.cixit.se>
Peter Karlsson wrote:
> gapon:
>
>> i have discovered "weird" behaviour of git in this scenario*:
>
> Yeah, I have run into it several times myself, and that is being both
> user A and B at the same time. The problem seems to be that git allows
> you to push into a repository which has a check-out, causing it to
> change states in a subtle way. That's just plain broken.
>
> Git should either handle it somehow (perhaps by forcing the push into a
> new branch, which the pushee needs name), or just plainly refuse to
> push into a repository with a check-out.
I thought that modern git refuses to push into checked out branch
(in HEAD) in non-bare repositories. In shared repositories default
is to deny non-fastforwards, by the way.
> I have learned to work around this problem by always pulling between my
> repositories, not pushing.
You can simply push to remotes, allowing other person to merge
on other side.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-27 15:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ,
Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711271352050.27959@racer.site>
Johannes Schindelin wrote:
> 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".
>
Let me rephrase.
For any project large enough to want to attract random hackers, there
will always be a single repository considered the public "master repo".
For such projects code is most likely considered "published" when the
code hits that repository (or some middle-stage on its way to it).
It has to do with communication and convenience. When the code reaches
that master repo it's no longer easy to communicate the fact that it
has been rebased to everyone it's been published to.
> Just because you use git like cvs does not mean that you "use git".
>
I suppose Junio and Linus don't "use git" either then, as they're both
in control of at least one such "master repo" each. Ah well. At least
I'm in good company.
>> 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.
It's not only convenient for me. It's convenient for the tens of thousands
of people working on the Linux kernel to have a single place to go to for
that one repository that somehow fathers all the tarballs.
So long as it's a small group of developers working on something, it's
obviously not necessary to provide such a place, but when you want to
attract the huge anonymous coders that you've never spoken to, you need
a single place to post the latest and greatest.
> 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.
>
So? Any new developer wanting to work on it will still try to locate
the public copy of the "master repo" to start their fork from.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-27 15:19 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <20071127150829.GB3853@fieldses.org>
On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > 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.
>
> Right. But a rebase "merge strategy" doesn't work for those people,
> because it's not possible in general for their git to know exactly which
> part is their work (which needs to be rebased) and which is your old
> work (which should be discarded). Manual inspection is required.
I don't follow.
Their work is always origin/master@{1}..HEAD after origin/master has
been updated through a fetch, and it needs to be rebased on
origin/master.
> > And in this case, constant rebasing is a perfectly fine work flow to me.
>
> Again, if you have people basing work on top of yours, I think the best
> option may really be to add a merge commit on top of each new version of
> the series with first parent the new series and second parent the
> previous history.
>
> That way the history does have the information necessary to rebase their
> work automatically.
And my repo will then be full of clutter which no one upstream will ever
accept to merge. Can't do that.
Nicolas
^ permalink raw reply
* [PATCH] git-gui: Improve the application icon on Windows.
From: Johannes Sixt @ 2007-11-27 15:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
Previusly, there was only a 16x16 image, which looked very distorted.
Here we add a 32x32 version, and also make the image sharper.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I'm by far not an artist, but improving the previous version
was not difficult at all. ;)
-- Hannes
git-gui/lib/git-gui.ico | Bin 318 -> 3638 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/git-gui/lib/git-gui.ico b/git-gui/lib/git-gui.ico
index 563dd66238c1a5c169438fdb87ab797f6d19d1bc..334cfa5a1a59c320e86789ccf4ed3320584a0215 100644
GIT binary patch
literal 3638
zcmeH~ziSjh6vyA`iH8I(0ZDa`m_kiGRjLaq(go67oo?_yNF(H`v<gCCx)dr}*yJy`
zO2G`4Nn=2`A`k>G*c^D|`FXRq?%pQGAH+tom$y6b`)1zz?CjmnM5HD+WPV=K@v0$m
zpVstr=0Cb6@&WB3?mV`P)dYc~TThn@PF;e?-EMZ_OjCNjp7cKUWbpo_)a!L=G#WBB
zH6=4MGcr3nE3H;b78Vv{adA;PosO)nt;x#DiYzTHN%yhJ`nt+9IS~CE<?X>2IXFI+
zr?1~o$YCA}Sj=39=Fl9PGflHD9^IpRbdT=QZCF4L=m9672XrnH(Ia|9j|dT6@fBZV
zs_ZyB>N^rS202kl<vBSR91IQy2SY-F!NK5Qa4<L+5+)1|1_y(K!NHKwVQ?@w7#s`^
z2B&CnI5?bfsHPb};cB0NMGW0;85U1*Pa#iI4@;T`f}Vzl#lw=O1r85~hr`3+;Yd>j
zhljz#;9;<-^Kf_=JPeUq$~jFTb+QkBnqHe7sHh$2m8P270j5CFK!E^Lpmrb_ND`<W
zsGS~1s*O(lK>a{{dqjcyfw>7V1Q-JIV2_PiNq3LJm9srY<{(lp!WQ9()Ju=nIGBS7
zM>Gy@EIn=pMOY#%5r{~^^c8?5GBDC9B1BmD!^p!kiLgYQkHli%273x<FenTPgTkON
zC=BWA1Ve;DVNe(%45Y#64}-#>FenV9#?WC<7!(EtK&c-|rVLa%d2)Ds4~M4Q*2l{|
zc_AAc8?w2%DcjrIva_=z`}_N{x3?#Uhlg@>bR_+LUrtU=<n;7ZhQpx@zNtLl-Q{=O
zWp?d1U>EWw&+?k9a;G@%7Dpi#ts+XRkn`3=_<V;-xY{9wCsXB~T_?il+)SwU|5HCh
zqSCltb^LF~$G2J@U);brn3XAYG2Pss#Vv4Yyp-#2nyZzgnxhh4z3O<Dk5!~o&0O~X
zUEDI4k8)LOmt)qx>Ufs#qRiz=S0C3;H&uHz)oywvY@Ia+?a|z@J<31LR(q68+GkB^
ztJxDQKhj%e{5rArh)~&n5x0GcZC&QEe4nyh!@2P2vPU7nJ1t!})4blNuqLrYVb}YV
z>wOA)iT`z<k}ZxuUWoZxITnf)G83`|)0WiSr-4)P$HVAjfs}KcuzJbYz+A8T=+%W`
t!ne1#9r^goEBwpG59dS%O_BaP5&n&m{sZi`$XCqvauzc?+sdr!e+Q6k)cF7a
literal 318
zcmZ{aI}XAy5JV>uJ$7MQDAOPcghU60DUcAtknN#y8;J{W6>gFv&{A`PAPRmFV(kqb
zS!;GYZx%@SDW!O~kS0I}K+00A9xL#s+3xo6-ebNzqCY-kQB0do|8gSInpZISaEic)
zJMD~%z0r(_oRhmXtwN+BPw>r1oU&Pn^z+Qx2&}bP<Pz(?ngC@RxSfDI>yiW4F7RUZ
SE~I<%|8o#MxGM)hRp&1`Pe2d=
--
1.5.3.6.969.g3cdf46
^ permalink raw reply
* Re: [PATCH RFC] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-27 15:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20071127150229.GA14859@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 390 bytes --]
On Tue, 27 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> We have talked about it for quite some time now. How about
> making it happen? I won't miss dashed form commands much :)
>
> A compromised approach could be keeping porcelain commands
> in bindir, only plumbings are moved to libexecdir. That would
> be less shock than this.
I think that would be an excellent idea.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-27 15:34 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711271013310.9605@xanadu.home>
On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>
> > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > > 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.
> >
> > Right. But a rebase "merge strategy" doesn't work for those people,
> > because it's not possible in general for their git to know exactly which
> > part is their work (which needs to be rebased) and which is your old
> > work (which should be discarded). Manual inspection is required.
>
> I don't follow.
>
> Their work is always origin/master@{1}..HEAD after origin/master has
> been updated through a fetch, and it needs to be rebased on
> origin/master.
No, their work isn't always based on origin/master@{1}. Often they've
got more than one project going. If they try
git checkout project-1
git pull -s rebase
git checkout project-2
git pull -s rebase
what's going to happen? What if project-2 has been on the back burner
for a few months and they're just getting around to rebasing it now?
What if their various projects are based on different upstream branches,
but the fetch done by git-pull updates them all at once? What if they
did a git fetch earlier just to peek at current development and are only
now getting around to updating their own branches?
And I don't think any of those are crazy corner cases; I know at least
that I do all of those things.
> > Again, if you have people basing work on top of yours, I think the best
> > option may really be to add a merge commit on top of each new version of
> > the series with first parent the new series and second parent the
> > previous history.
> >
> > That way the history does have the information necessary to rebase their
> > work automatically.
>
> And my repo will then be full of clutter which no one upstream will ever
> accept to merge. Can't do that.
No, it's no problem--you just submit branch^. You probably want to give
it a throw-away name for the purpose of the request-pull message, e.g.:
git branch for-linus HEAD^
git push my-pub-repo for-linus
then delete for-linus after you see it merged.
But use for-linus only for that, and advertise "branch" as the base
people should be using for ongoing development.
I don't know, maybe it's too complicated. But I think it's the only way
to get a really robust automated process for the people basing work on
your branch.
--b.
^ permalink raw reply
* Re: [PATCH] git-gui: Improve the application icon on Windows.
From: Johannes Schindelin @ 2007-11-27 15:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <1196177124-13601-1-git-send-email-johannes.sixt@telecom.at>
Hi,
On Tue, 27 Nov 2007, Johannes Sixt wrote:
> Previusly, there was only a 16x16 image, which looked very distorted.
> Here we add a 32x32 version, and also make the image sharper.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> I'm by far not an artist, but improving the previous version
> was not difficult at all. ;)
Why did you not just use the svg contained in msysGit?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Move all dashed form git commands to libexecdir
From: Nguyễn Thái Ngoc Duy @ 2007-11-27 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <20071127150229.GA14859@laptop>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Both configure and make-only ways should work now
Makefile | 2 +-
config.mak.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 313f9a2..377d7be 100644
--- a/Makefile
+++ b/Makefile
@@ -154,7 +154,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
-gitexecdir = $(bindir)
+gitexecdir = $(prefix)/libexec/git-core
sharedir = $(prefix)/share
template_dir = $(sharedir)/git-core/templates
ifeq ($(prefix),/usr)
diff --git a/config.mak.in b/config.mak.in
index 11d256e..1db0338 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -11,7 +11,7 @@ TCLTK_PATH = @TCLTK_PATH@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
+gitexecdir = @libexecdir@/git-core/
datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates/
--
1.5.3.GIT
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-27 16:14 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <20071127153411.GA11731@fieldses.org>
On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 10:19:53AM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> >
> > > On Tue, Nov 27, 2007 at 09:29:21AM -0500, Nicolas Pitre wrote:
> > > > 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.
> > >
> > > Right. But a rebase "merge strategy" doesn't work for those people,
> > > because it's not possible in general for their git to know exactly which
> > > part is their work (which needs to be rebased) and which is your old
> > > work (which should be discarded). Manual inspection is required.
> >
> > I don't follow.
> >
> > Their work is always origin/master@{1}..HEAD after origin/master has
> > been updated through a fetch, and it needs to be rebased on
> > origin/master.
>
> No, their work isn't always based on origin/master@{1}. Often they've
> got more than one project going. If they try
>
> git checkout project-1
> git pull -s rebase
> git checkout project-2
> git pull -s rebase
>
> what's going to happen? What if project-2 has been on the back burner
> for a few months and they're just getting around to rebasing it now?
I don't see the problem. They'll just have a possibly harder rebase due
to increased chances for conflicts than if they rebased more often, but
that's to be expected even with a merge.
> What if their various projects are based on different upstream branches,
> but the fetch done by git-pull updates them all at once?
> What if they
> did a git fetch earlier just to peek at current development and are only
> now getting around to updating their own branches?
You are not _forced_ to use origin/master@{1} in that case -- I used
that notation only to illustrate the concept in Git terms. What I tell
people to do is to tag their new base after the rebase is done, and to
use that tag after the next fetch to rebase again.
I honnestly don't use such a tag myself because I think I know what I'm
doing when using Git, and therefore I know when origin/master@{1} refers
to what I really want. But the point is that either that usage of
origin/master@{1}, or a dedicated tag, or whatever other means to
retrieve the previous base, could be handled implicitly by the porcelain
and the user wouldn't have to care as much.
Thinking about it, there should be a way to find the proper base even
without explicitly recording it with a tag. If it isn't
origin/master@{1}, it has to be the first of origin/master@{n} for
n = [1, ...] reachable from the local work branch before rebasing.
> And I don't think any of those are crazy corner cases; I know at least
> that I do all of those things.
Sure. In which case you certainly fall into the "know what you're
doing" category too and certainly can find your way towards the proper
base ref to use. But again I think that can be automated.
> > > Again, if you have people basing work on top of yours, I think the best
> > > option may really be to add a merge commit on top of each new version of
> > > the series with first parent the new series and second parent the
> > > previous history.
> > >
> > > That way the history does have the information necessary to rebase their
> > > work automatically.
> >
> > And my repo will then be full of clutter which no one upstream will ever
> > accept to merge. Can't do that.
>
> No, it's no problem--you just submit branch^. You probably want to give
> it a throw-away name for the purpose of the request-pull message, e.g.:
>
> git branch for-linus HEAD^
> git push my-pub-repo for-linus
>
> then delete for-linus after you see it merged.
>
> But use for-linus only for that, and advertise "branch" as the base
> people should be using for ongoing development.
>
> I don't know, maybe it's too complicated. But I think it's the only way
> to get a really robust automated process for the people basing work on
> your branch.
It just looks too twisted for my taste when proper automatic rebase
without extra artifacts should be possible.
Nicolas
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-27 16:18 UTC (permalink / raw)
To: Nguyễn Thái Ngoc Duy; +Cc: git
In-Reply-To: <20071127160423.GA22807@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 199 bytes --]
Hi,
On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
> Both configure and make-only ways should work now
I thought your plan was to put the non-porcelain into the libexecdir only?
Ciao,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Linus Torvalds @ 2007-11-27 16:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711262346410.9605@xanadu.home>
On Mon, 26 Nov 2007, Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>
> > - Loose objects storage is difficult to work with
> >
> > The standard loose object format of DEFLATE("$type $size\0$data")
> > makes it harder to work with as you need to inflate at least
> > part of the object just to see what the hell it is or how big
> > its final output buffer needs to be.
>
> It is a bit cumbersome indeed, but I'm afraid we're really stuck with it
> since every object SHA1 depends on that format.
No.
The SHA1 itself just depends on "$type $size\0$data" (no deflate phase),
and that one is easy and cheap to calculate. How we then *encode* the data
on disk is totally immaterial.
In fact, pack-files obviously do not encode it in that form at all, they
in fact use two different forms of "$binaryhdr$DEFLATE($data)" or
"$binaryhdr$basesha$DEFLATE($delta)" (that's from memory, so don't rely on
that).
So we could easily change the on-disk format, and we obviously have - the
alternate (but deprecated) format for unpacked objects already did. In
fact, we could - and probably should - add some kind of "back end
interface" for alternate encoding formats, in case somebody wants to do
something really crazy like use a database for object tracking.
(Side note: using an actual database would really be insane. There is
absoluely zero point. But what *could* be interesting would be to have a
"cluster back-end" for the git object store, where objects get hashed to
different nodes. If you have a really fast network, it may actually be
beneficial to spread the objects out, and get better disk throughput by
that kind of strange "git object RAID-0 striping" setup)
Linus
(*) Honesty in advertising: the really *original* format did the SHA1
after the deflate, but that was quickly fixed and was a really stupid
choice. The main point for doing that was that it meant that loose objects
could be verified by just running "sha1sum" on them, and comparing the
result with their name.
^ 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