* 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
* Re: git bug/feature request
From: Alex Riesen @ 2007-11-27 16:36 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271445.47695.gapon007@gmail.com>
On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > 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
No, thanks. It is easy to reproduce
^ permalink raw reply
* git-cvsimport bug
From: Emanuele Giaquinta @ 2007-11-27 15:01 UTC (permalink / raw)
To: git
Hi,
a call to git-cvsimport after a 'git-pack-refs --all' seems to mess up
the origin branch, because the first new change is committed with no
parent (git-cvsimport reports 'Parent ID (empty)').
It does not happen if I disable loose refs pruning with --no-prune. A
tiny test repo you can use to reproduce the problem is
mextli.tomaw.net/~exg/lzf.tar. Is it expected?
Thanks,
Emanuele Giaquinta
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-27 16:42 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711271047590.9605@xanadu.home>
On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > 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.
Well, fair enough. It can be much worse than a merge, though--consider
what happens when upstream drops a commit, or replaces a patch by
another patch (or patches) that solves the problem in a different way.
> > 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.
That's fine, but it's not an automated process any more.
> 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.
OK, so you're imagining a version of "git pull -s rebase" that also
allows specifying the previous base of your series? What would the
syntax be? You could do something like stg does and keep extra
information under .git that records the base of each "patch series".
Then you have to figure out how to manage that information and how it
should interact with the varoius branch management commands.
> 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.
That'll work in some cases. You're almost using the reflog as another
piece of history to find the "real" merge-base.
That's a little fragile, since reflogs aren't quite "real" history. It
doesn't work reliably in the "project that was put on the back burner"
case (because the reflog entries may have expired). It doesn't work if
work is done in multiple repositories.
> > 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.
Beginners are will try those things too, so we'd have to explain the
limitations up front.
> But again I think that can be automated.
I'd want to see the algorithm spelled out, and a very convincing
description of exactly which cases it handles.
My other objection is that "rebase" just isn't a merge strategy. I
think of a merge strategy takes some HEADs in a produces a single merge
commit that connects them.
If we really want a fetch+rebase script, OK, but call it something other
than pull.
--b.
^ permalink raw reply
* Re: [PATCH] Tweak git-quiltimport to allow more flexible series format
From: Alexey Dobriyan @ 2007-11-27 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, adobriyan
In-Reply-To: <7vsl2x26di.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 03:43:53PM -0800, Junio C Hamano wrote:
> Alexey Dobriyan <adobriyan@sw.ru> writes:
>
> > Make quiltimport also understand comments following patch name.
> >
> > Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
> > ---
> >
> > git-quiltimport.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/git-quiltimport.sh
> > +++ b/git-quiltimport.sh
> > @@ -63,7 +63,7 @@ tmp_info="$tmp_dir/info"
> > commit=$(git rev-parse HEAD)
> >
> > mkdir $tmp_dir || exit 2
> > -for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
> > +for patch_name in $(sed -e 's/#.*//' < "$QUILT_PATCHES/series" ); do
> > if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
> > echo "$patch_name doesn't exist. Skipping."
> > continue
>
> Is this consistent with the way quilt groks the series file?
>
> IOW, does quilt forbid patchfile whose name contains a hash, and
> anything after a hash on the line is taken as comment?
It looks like hash inside a patch name is legal.
> Can a line in a quilt series file name more than one patchfile?
No. Which means we can probably do sed -e 's/^#//' -e 's/[ \t]#.*//'
... let me experiment bit more.
> If so, are they whitespace separated?
^ 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