* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 8:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, git
In-Reply-To: <20071019080755.GO14735@spearce.org>
On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:
> Then you get linewrap on smaller terminals, and bigger ones don't
> line up the right side. *shrug*
Bigger ones will line up, just not on the far right side of the
terminal. I guess we ought to support smaller terminals, though).
> > > + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
> > Hrm, btw, I can't seem to get this one to show (I was curious how ugly
> > the FETCH_HEAD would look).
> Yea, I can't easily see how to get this to generate.
I thought "git-fetch bare_url" would do it, since then we have no
remote fetchspec to look up, but it doesn't.
> > Also, I was unable to generate a test case that showed this one. Did
> > you?
> git fetch -v jc
Ah, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Shawn O. Pearce @ 2007-10-19 8:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <47186563.3070607@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> >I think it is already in Paul's repo:
>
> No, it's not. I checked both Paul's master and dev, and also your own
> gitk branch. Would you mind cherry-picking from the tip of
>
> git://repo.or.cz/git/mingw.git mob
Picked. Its now in spearce/gitk.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Sixt @ 2007-10-19 8:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Shawn O. Pearce schrieb:
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
>
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
>
> The width of the terminal is computed to produce the ... padding.
I like the wording of the status tags.
But the padding does not convince me. How does this look on very wide
terminals? Maybe use 80 as a maximum?
> + if (ws_cols) {
> + size_t n = strlen(status) + strlen(remote_name) + 2;
> + if (op)
> + n += 1 + strlen(op);
> + if (local_name)
> + n += 1 + strlen(local_name);
> + n = ws_cols - n - strlen(reason) - 4;
> + fputc(' ', stderr);
> + while (n--)
> + fputc('.', stderr);
while (n-- > 0)
otherwise you're screwed if your terminal is too narrow.
> +static void determine_window_size(void)
> +{
#ifdef TIOCGWINSZ
> + struct winsize ws;
> + if (!ioctl(2, TIOCGWINSZ, &ws))
> + ws_cols = ws.ws_col;
#endif
> +}
Pretty please. We don't have TIOCGWINSZ on Windows.
-- Hannes
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Le Fri, 19 Oct 2007 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> svn ci -m 'Add README.'
# forgot this
svn up
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
It's the same, with --follow-parent and with --no-follow-parent .
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: David Kastrup @ 2007-10-19 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <?= =?ISO-8859-1?Q?2007101=049081127.?= =?ISO-8859-1?Q?GA30168@coredump?= =?ISO-8859-1?Q?.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:
>
>> Then you get linewrap on smaller terminals, and bigger ones don't
>> line up the right side. *shrug*
>
> Bigger ones will line up, just not on the far right side of the
> terminal. I guess we ought to support smaller terminals, though).
I don't see why. 80 columns has been the standard layout for
something like 40 or 50 years or so. It is the standard punch card
width and required to display Fortran code fitted to this width
(column 73 to 80 are ignored in non-free-format Fortran and used for
line identification).
All people using smaller terminals are used to wrapping trouble. We
really don't need to go overboard supporting Commodore 64 users with
git.
--
David Kastrup
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 7:51 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Le Fri, 19 Oct 2007 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> I've surprised myself but yes, there is a simple testcase.
>>
svnadmin create repo
svn checkout file://$PWD/repo checkout cd checkout/
svn mkdir trunk tags branches
svn ci -m 'Standard svn layout.'
cd trunk/
svn mkdir doc
touch doc/README
svn add doc/README
svn ci -m 'Add README.'
# forgot this, sorry
svn up
cd ..
svn mv trunk/ branches/oldtrunk
svn ci -m 'Moved trunk.'
svn mkdir trunk
svn ci -m 'New trunk.'
cd trunk/
touch THIS_IS_THE_NEW_TRUNK
svn add THIS_IS_THE_NEW_TRUNK
svn ci -m 'Add marker.'
cd ../..
git svn clone file://$PWD/repo --stdlayout git-clone
cd git-clone/
tree
>>
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
It's the same whether I use --follow-parent or --no-follow-parent .
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 8:17 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Vendredi 19 Octobre 2007 à 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> svn ci -m 'Add README.'
# forgot this:
svn up
>> cd ..
>> svn mv trunk/ branches/oldtrunk
>>
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
The result is the same, whether I use --follow-parent
or --no-follow-parent .
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 8:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <864pgncy9y.fsf@lola.quinscape.zz>
On Fri, Oct 19, 2007 at 10:19:05AM +0200, David Kastrup wrote:
> I don't see why. 80 columns has been the standard layout for
> something like 40 or 50 years or so. It is the standard punch card
> width and required to display Fortran code fitted to this width
> (column 73 to 80 are ignored in non-free-format Fortran and used for
> line identification).
I almost said that, but it seems unnecessarily restrictive. Do people
use git on handhelds (or use them to connect to decent machines that run
git)? If it's related to the actual functioning of the program, then
fine, but it seems unnecessarily strict for something that is just eye
candy anyway.
> All people using smaller terminals are used to wrapping trouble. We
That is a good point...people on tiny screens are likely to be wrapping
on the _other_ lines anyway. I wonder how awful our progress meters look
on a tiny terminal.
Really, I'm fine with assuming an 80 char terminal. I just didn't want
to be in the position of defending it as a useful feature when somebody
complained.
-Peff
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 8:58 UTC (permalink / raw)
To: Jan Wielemaker
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <200710190943.45201.wielemak@science.uva.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Wielemaker wrote:
> On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
>> We are definitely not fine with CVS, the branch merging isn't
>> comfortable. I'm just wondering about maintaining the existing
>> CVS browsers and the build scripts if it's not a big deal. I'll
>> try the git-cvsserver path. If anyone has any war stories to share
>> on the path this would be an ideal time to share them.
>
> As for web browsing the history, our project was quickly convinced
> gitweb is a lot better than cvsweb. We are starting to get use to
> basic git. One developer works on CVS. This is a bit handicapped,
> but workable after a few patches to git-shell and git-cvsserver.
Could you tell me a bit more about those patches and the need for using
git-shell (haven't even messed with that yet).
Think I can set things up so the CVS updates, checkouts, and the
like that are being used on our build machines can remain untouched
and have the git-cvsserver exactly acting like the current CVS server.
It would be nice if branches and tags work without touching all of the
build machines and their scripts.
I don't think we need to have any developers continuing to use CVS;
but I may be wrong. I think I read that there's a limitation to being
on the main branch and unfortunately most of out tags are on a release
branch.
- -piet
>
> In another project I use git-cvsserver to do the Windows builds.
> All development except for minor typos and compatibility things is
> done on linux and cvs <-> git works just fine for that model.
>
> --- Jan
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHG9JICwm/rv3hoRApQIAJ0Ys6QwxnBAu9tNWrGLU9svwtYXZwCeIFlq
Yr8snPT8TW/nBxFygFr95Ik=
=MtJS
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-19 9:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, dan
When matching source and destination refs, we were failing
to pull the 'force' parameter from wildcard respects (but
not explicit ones) and attach it to the ref struct.
This adds a test for explicit and wildcard refspecs; the
latter fails without this patch.
Signed-off-by: Jeff King <peff@peff.net>
---
remote.c | 2 ++
t/t5400-send-pack.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index b20e2be..170015a 100644
--- a/remote.c
+++ b/remote.c
@@ -762,6 +762,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
hashcpy(dst_peer->new_sha1, src->new_sha1);
}
dst_peer->peer_ref = src;
+ if (pat)
+ dst_peer->force = pat->force;
free_name:
free(dst_name);
}
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 57c6397..2d0c07f 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -123,4 +123,52 @@ test_expect_success \
git-branch -a >branches && ! grep -q origin/master branches
'
+rewound_push_setup() {
+ rm -rf parent child &&
+ mkdir parent && cd parent &&
+ git-init && echo one >file && git-add file && git-commit -m one &&
+ echo two >file && git-commit -a -m two &&
+ cd .. &&
+ git-clone parent child && cd child && git-reset --hard HEAD^
+}
+
+rewound_push_succeeded() {
+ cmp ../parent/.git/refs/heads/master .git/refs/heads/master
+}
+
+rewound_push_failed() {
+ if rewound_push_succeeded
+ then
+ false
+ else
+ true
+ fi
+}
+
+test_expect_success \
+ 'pushing explicit refspecs respects forcing' '
+ rewound_push_setup &&
+ if git-send-pack ../parent/.git refs/heads/master:refs/heads/master
+ then
+ false
+ else
+ true
+ fi && rewound_push_failed &&
+ git-send-pack ../parent/.git +refs/heads/master:refs/heads/master &&
+ rewound_push_succeeded
+'
+
+test_expect_success \
+ 'pushing wildcard refspecs respects forcing' '
+ rewound_push_setup &&
+ if git-send-pack ../parent/.git refs/heads/*:refs/heads/*
+ then
+ false
+ else
+ true
+ fi && rewound_push_failed &&
+ git-send-pack ../parent/.git +refs/heads/*:refs/heads/* &&
+ rewound_push_succeeded
+'
+
test_done
--
1.5.3.4.1254.gc1ca9-dirty
^ permalink raw reply related
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-19 9:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, dan
In-Reply-To: <20071019090400.GA8944@coredump.intra.peff.net>
On Fri, Oct 19, 2007 at 05:04:00AM -0400, Jeff King wrote:
> to pull the 'force' parameter from wildcard respects (but
Urgh, that should be "refspecs", not "respects". Maybe I should quit for
the night.
-Peff
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 9:12 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Marco Costalba, Johannes Schindelin, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4718594A.2070407@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
> Pete/Piet Delaney wrote:
>> Johannes:
>> I read somewhere in the past week that it was possible to maintain
>> our existing CVS environment with git. I though it was a separate
>> package to export git back to cvs but I just noticed a git-cvsserver
>> and as a std part of git and was wondering about using that.
>>
>> We have a number of build machines with flamebox perl scripts pulling
>> out CVS branches for builds. I was wondering what is the best way to
>> use git and it's nicer pull/push model and merge facility and possibly
>> maintain CVS exports for scripts doing builds if possible the cvsweb
>> and bonsai (CVS Query Form) that a number of engineers are currently
>> using. I started looking over out flamebox scripts with the intent
>> up converting them over to git but I mentioned the git to cvs
>> coexistence and we are wondering if that's a better route than
>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>> and gitweb along with the git utilities seems at least desirable.
>> Any thoughts or suggestions?
>>
>
> If you do convert them to git, you can fairly easily do an automatic
> bisect on build-errors, and the developer can (after some time) get
> an email of what machines they broke the code on and what the bad
> commit was.
Could you explain that a bit more. Sounds like you saying it's worth
messing with the flamebox scripts to use git instead of using the git
cvserver and letting them pull the cvs branches as they do now. Is the
existing flamebox email of build log effected buy switching form cvs
to git? I hadn't expect it to change.
> Besides that, it's not a black-and-white scenario. If I were you I'd set
> up git-cvsserver and make sure that works for all the scripts, and then
> pick one or two auto-build things to convert to git. Preferrably on a
> separate machine, so everything keeps working the same as always while
> you're fiddling with the auto-build stuff.
I get the impression your suggestion to first get git-cvsserver serving
the repo so that the build machines works without any change and then to
go to each build machine and update the scripts to use git instead of cvs.
Are there any tricks I need to so on the repo to make the branches pull
out with exactly the same commands that we are currently using. My guess
is that the branch checkouts should work without any messing around.
>
> Just my two cents.
Hey, you two cents could easily save me hours of messing getting this
conversion done.
BTW, I don't think anyone is checking into the repo, but if they do
can I do another git-cvsimport to just update the one I already did?
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHUUJICwm/rv3hoRArHsAJ9GQMjpLc5CzpBXnHkxLfBgfwEo/QCdGNfj
DiivgfDDSbIB+9YBZvj/5Z0=
=SBSg
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Andreas Ericsson @ 2007-10-19 9:52 UTC (permalink / raw)
To: pete
Cc: Marco Costalba, Johannes Schindelin, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <47187518.1090007@bluelane.com>
Pete/Piet Delaney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andreas Ericsson wrote:
>> Pete/Piet Delaney wrote:
>>> Johannes:
>>> I read somewhere in the past week that it was possible to maintain
>>> our existing CVS environment with git. I though it was a separate
>>> package to export git back to cvs but I just noticed a git-cvsserver
>>> and as a std part of git and was wondering about using that.
>>>
>>> We have a number of build machines with flamebox perl scripts pulling
>>> out CVS branches for builds. I was wondering what is the best way to
>>> use git and it's nicer pull/push model and merge facility and possibly
>>> maintain CVS exports for scripts doing builds if possible the cvsweb
>>> and bonsai (CVS Query Form) that a number of engineers are currently
>>> using. I started looking over out flamebox scripts with the intent
>>> up converting them over to git but I mentioned the git to cvs
>>> coexistence and we are wondering if that's a better route than
>>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>>> and gitweb along with the git utilities seems at least desirable.
>>> Any thoughts or suggestions?
>>>
>> If you do convert them to git, you can fairly easily do an automatic
>> bisect on build-errors, and the developer can (after some time) get
>> an email of what machines they broke the code on and what the bad
>> commit was.
>
> Could you explain that a bit more. Sounds like you saying it's worth
> messing with the flamebox scripts to use git instead of using the git
> cvserver and letting them pull the cvs branches as they do now. Is the
> existing flamebox email of build log effected buy switching form cvs
> to git? I hadn't expect it to change.
>
git has quite a wonderful tool named git-bisect. In short, it helps track
down what particular commit introduced a bug. Let's say your builds fail
for some reason, and the build-scripts send out the build-log to the
developer. The script can then continue to check the repo by running git
bisect on it and finding the commit that introduced the build-error, and
email that too to the developer. In short, when you check things in at
5 o'clock that doesn't build, you don't have to sit there and wrestle with
it. You can go home, have dinner, tuck the kids into bed, and then open
your mailbox and have an email with the exact commit that introduced the
regression.
Now, if you can also convince your developers to make small and isolated
commits, and your build-system is such that it doesn't rebuild *everything*,
but has proper dependency tracking and suchlike (a properly written Makefile
for example), the developer will get pointed to a commit that affects perhaps
10-20 lines of code within a reasonable time, and it should be so trivial to
fix that anyone can do it.
>
>> Besides that, it's not a black-and-white scenario. If I were you I'd set
>> up git-cvsserver and make sure that works for all the scripts, and then
>> pick one or two auto-build things to convert to git. Preferrably on a
>> separate machine, so everything keeps working the same as always while
>> you're fiddling with the auto-build stuff.
>
> I get the impression your suggestion to first get git-cvsserver serving
> the repo so that the build machines works without any change and then to
> go to each build machine and update the scripts to use git instead of cvs.
>
That's the idea, yes.
> Are there any tricks I need to so on the repo to make the branches pull
> out with exactly the same commands that we are currently using. My guess
> is that the branch checkouts should work without any messing around.
I'm not sure what you mean by that. You can tell git to automatically fetch
any new branches (that's the default, I think), but you'll ofcourse have to
switch to using git-pull instead of cvs co (or whatever you're using now),
unless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well
enough that it accepts all commands and the two are interchangeable (assuming
the background repo conversion has been done, ofcourse).
>> Just my two cents.
>
> Hey, you two cents could easily save me hours of messing getting this
> conversion done.
>
That's well-invested money then ;-)
> BTW, I don't think anyone is checking into the repo, but if they do
> can I do another git-cvsimport to just update the one I already did?
Yes. It works incrementally, but since cvs commits aren't atomic, you
have to wait 10 minutes after the cvs commit *starts* to be able to
use cvsimport to move it over to git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Santi Béjar @ 2007-10-19 10:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Another possibility is with just some minor reductions from the
current output, as:
$ git fetch spearce
...
From git://repo.or.cz/git/spearce
* spearce/gitk: fast forward to branch 'gitk'
old..new: 0d6df4d..2b5afb7
* spearce/maint: fast forward to branch 'maint'
old..new: 1aa3d01..e7187e4
* spearce/master: fast forward to branch 'master'
old..new: de61e42..7840ce6
* spearce/next: fast forward to branch 'next'
old..new: 895be02..2fe5433
* spearce/pu: forcing update to non-fast forward branch 'pu'
old...new: 89fa332...1e4c517
This way it is slightly less terse than the other proposals but not
that cryptic and it normally fits in one line without padding. And I
really like to see what has changed explicitly with the old..new line.
Santi
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Andreas Ericsson @ 2007-10-19 10:40 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20071019062219.GA28499@coredump.intra.peff.net>
Jeff King wrote:
> - we abbreviate the local refs (chopping refs/heads,
> refs/tags, refs/remotes). This means we're losing
> information, but hopefully it is obvious when storing
> "origin/master" that it is in refs/remotes.
I like this, since "origin/master" is how that branch is supposed to
be used.
> - fast forward information goes at the end
> - cut out "Auto-following ..." text
>
> What do people think? Some changes? All?
>
Possibly re-listing "refused" messages last so users who pull from
repos with a huge amount of branches can see it at the bottom.
> Other questions:
> - Is the "==>" too ugly? It needs to be short (many urls
> are almost 80 characters already), and it needs to stand
> out from the "resolving deltas" line, so I think some
> symbol is reasonable.
Skip the marker altogether and indent the output two spaces.
> - Should we omit "(fast forward)" since it is the usual
> case?
I think so, yes, or perhaps just shorten it to 'ff' so the 'refused' and
'merged' messages stand out a bit more.
> - Should refs/remotes/* keep the "remotes/" part?
I think not. It's used as origin/master (by end-users anyways), so writing
what they're familiar with is most likely the correct thing to do.
> - How annoying is the doubled '==> $url' line? It comes
> from the fact that we fetch the tags separately.
>
Fairly annoying. I'd prefer if it was squelched the second time.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Andreas Ericsson @ 2007-10-19 10:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Shawn O. Pearce wrote:
>
> What about this on top of Jeff's patch?
>
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
>
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
>
> The width of the terminal is computed to produce the ... padding.
> I used a very narrow terminal to produce the above so it doesn't
> linewrap badly in email. If we cannot get the terminal width then
> we just don't produce the padding.
>
Melikes, although using a fairly narrow padding isn't necessarily
a bad idea. I usually hate it when the output on the left is 15 chars
wide, the one on the right is 5-10 chars wide and there are 60 dots
between them. It's ugly and doesn't make it a easier to read.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jan Wielemaker @ 2007-10-19 10:34 UTC (permalink / raw)
To: pete
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <471871BD.7030608@bluelane.com>
On Friday 19 October 2007 10:58, Pete/Piet Delaney wrote:
> Jan Wielemaker wrote:
> > On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> >> We are definitely not fine with CVS, the branch merging isn't
> >> comfortable. I'm just wondering about maintaining the existing
> >> CVS browsers and the build scripts if it's not a big deal. I'll
> >> try the git-cvsserver path. If anyone has any war stories to share
> >> on the path this would be an ideal time to share them.
> >
> > As for web browsing the history, our project was quickly convinced
> > gitweb is a lot better than cvsweb. We are starting to get use to
> > basic git. One developer works on CVS. This is a bit handicapped,
> > but workable after a few patches to git-shell and git-cvsserver.
>
> Could you tell me a bit more about those patches and the need for using
> git-shell (haven't even messed with that yet).
One patch concerned handling "cvs update -p", which was accepted and I
guess will end up in the stable version someday. One concerned handling
"cvs diff -c", which I never submitted. I first tried a more general
approach to get diff option processing complete, but I had to backtrack
on that. Now I have a quite simple hack, but more complete coverage of
diff option processing requires a bit more perl knowledge than I have.
I submitted a patch for shell.c to make it call "git cvsserver server"
if a commandline "cvs server" was passed to it, so you can do CVS+SSH
compatible to normal CVS. I got so many comments I decided to keep it
for myself for now.
> I don't think we need to have any developers continuing to use CVS;
> but I may be wrong. I think I read that there's a limitation to being
> on the main branch and unfortunately most of out tags are on a release
> branch.
No, you can checkout any GIT branch as it it were a CVS module.
--- Jan
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Andreas Ericsson @ 2007-10-19 10:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Shawn O. Pearce wrote:
>
> +static void determine_window_size(void)
> +{
> + struct winsize ws;
> + if (!ioctl(2, TIOCGWINSZ, &ws))
> + ws_cols = ws.ws_col;
> +}
> +
I'd suggest re-using term_columns() from help.c instead. It's been in there
since the git wrapper was rewritten in C, so it's had a bit of testing and
seems to work fairly well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-19 11:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071019052823.GI14735@spearce.org>
Shawn O. Pearce writes:
> The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
> Paul Mackerras (1):
> gitk: Fix bug causing undefined variable error when cherry-picking
>
> are available in the git repository at:
>
> git://repo.or.cz:/git/spearce.git gitk
OK, but ...
> Jonathan del Strother (2):
> gitk: Added support for OS X mouse wheel
> Fixing gitk indentation
This one is bogus. Firstly, it doesn't have "gitk:" at the start of
the headline (and "Fixing" should be "Fix"). Secondly, the actual
change itself is bogus. It changes an initial tab to 8 spaces on each
of 4 lines. I like it the way it is - and if he wanted to change it,
he should have changed it throughout the file, not just on 4 lines.
So that change is rejected.
The other changes are OK. If you could re-do your tree without
0d6df4de (and possible change "Added" to "Add" in e1b5683c while
you're at it), I'll do the pull.
Paul.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Wincent Colaiuta @ 2007-10-19 11:33 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, Jeff King, git
In-Reply-To: <A2491F60-A00E-412A-8389-1C9EB5EDFCEF@mit.edu>
El 19/10/2007, a las 4:29, Michael Witten escribió:
> Ah. Basically my 'pseudo-code' is correct, but redundant.
If I understood the original poster's proposal then I don't think
your code does what he asked for:
> What you want to happen is the following:
>
> git show HEAD:A.txt > path/B.txt
> git add path/B.txt
> mv A.txt B.txt
> git rm A.txt
>
> Is this correct?
Here you're copying the content of A.txt as it was in the last (HEAD)
commit, but from what the poster said he wants the content of A.txt
as it is staged in the index (that is, there may be staged but
uncomitted changes).
> Better:
>
>> mv A.txt path/B.txt
>> Point the index entry for A.txt to path/B.txt
Yes, that is basically what he was asking for, as I read it.
El 19/10/2007, a las 5:47, Jeff King escribió:
> Hrm. So you _do_ want to do an index-only move of A to B, in which
> case
> the suggestion of a "git-mv --cached" seems sensible. Though I'm
> curious
> why you want that.
I agree that git-stash can be used in this workflow but I can also
imagine cases where the proposed "git-mv --cached" might be a bit
nicer. I'm thinking of occasions where you just want to do something
like:
git mv --cached foo bar
git add --interactive bar
I'm not sure the proposed "--cached" switch should ever be the
default -- would need to ponder that one -- but I do think the switch
would be a nice addition.
Cheers,
Wincent
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Pierre Habouzit @ 2007-10-19 11:34 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]
On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> Thought folks here might get a kick out of this:
>
> http://blog.red-bean.com/sussman/?p=79
>
> Okay, my summary is slightly facetious, but that's basically the gist of
> what he's saying: you should choose Subversion rather than a DVCS because
> most of your users won't be smart enough to use the better tool.
>
> I can't say he's completely wrong, especially about the 20/80% idea
> (though I think "20%" is generous), but some of his specific arguments
> about DVCS are on the bogus side. "Centralized systems encourage code
> reviews," for one -- I challenge him to find a project with a more
> pervasive and effective code-reviewing culture than the git project.
Your argument is also bogus.
IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's
a social pattern. There are people that do it because they understand
it's a good and necessary sound thing to do, and there are the others.
Guess what, it has a lot to do with the 20%/80% line (that I would have
more described as the 2/98 but well…).
Put git into the hands of fools, they won't proofread their code more
or less than with svn. And they will shoot themselves into their foots
twice as often as with svn.
Though, for people that are able to deal with git and use it, git
allows way better code reviewing patterns than with svn, because you
can prepare a nice incremental branch that adds each new features you
worked on with small patches (see my parse-options series). With svn,
you can't do that, because there is no tool that allow you to record
those patches on your end, so you submit a big +4123/-2341 patch. That
makes peer reviewing really harder.
Of course the git community is a perfect example of how code should be
reviewed. But it's not because we use git, it's because we definitely
are in the "20%".
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Theodore Tso @ 2007-10-19 11:38 UTC (permalink / raw)
To: Santi Béjar; +Cc: Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190303l4ce996daqf5c8025c857ea8@mail.gmail.com>
On Fri, Oct 19, 2007 at 12:03:24PM +0200, Santi Béjar wrote:
> This way it is slightly less terse than the other proposals but not
> that cryptic and it normally fits in one line without padding. And I
> really like to see what has changed explicitly with the old..new line.
Same here.
I find the old..new information occasionally useful, since it allows
me to do the git diff --- something for which ORIG_HEAD isn't enough
when you are pulling multiple heads, such as in git. Can we keep that
optional via a config or an command-line option?
Hmm... how about this?
==> git://repo.or.cz/git/spearce.git
* branch gitk -> spearce/gitk (new)
* branch maint -> spearce/maint 1aa3d01..e7187e4
* branch master -> spearce/master de61e42..7840ce6
* branch next -> spearce/next 895be02..2fe5433
+ branch pu -> spearce/pu 89fa332...1e4c517
* branch todo -> spearce/todo (new)
If the branch is new, obviously old..new won't be useful. The
non-fast forward branch is getting indicated twice, once with the "+"
sign, and once with the triple dot in the range.
As far as the padding, it would be a pain to figure out how to make
the right hand column be padded so that it starts 3 spaces after the
longest " * branch foo -> bar" line, but that would look the best.
Finally, one last question --- am I the only one who had to take a
second look at the whether the arrow should be <- or ->? The question
is whether we are saying "gitk is moving to include all of
spearce/gitk"; but I could also see it stated that we are assigning
refs/heads/gitk with refs/remotes/spearce/gitk, in which case the
arrow should be reversed. Or maybe:
==> git://repo.or.cz/git/spearce.git
* branch gitk := spearce/gitk (new)
* branch maint := spearce/maint 1aa3d01..e7187e4
* branch master := spearce/master de61e42..7840ce6
* branch next := spearce/next 895be02..2fe5433
+ branch pu := spearce/pu 89fa332...1e4c517
* branch todo := spearce/todo (new)
(Or is that too Pascal-like? :-)
- Ted
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Wincent Colaiuta @ 2007-10-19 11:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, Jeff King, git
In-Reply-To: <20071019034501.GG14735@spearce.org>
El 19/10/2007, a las 5:45, Shawn O. Pearce escribió:
> Nicolas Pitre <nico@cam.org> wrote:
>>
>> And imagine that you see the progress moving slowly because the
>> remote
>> server is a NSLU2, but it says 80%. Then you go for a coffee and the
>> progress says 20% when you return because it now has moved to a
>> different phase. Rather counter intuitive.
>
> Yea, I didn't consider that. That's where you need to show the
> number of steps and which one you are on, so the meter looks
> more like:
>
> Step 1/3: Counting objects: .... \r
> Step 2/4: Compressing objects: ... \r
> Step 3/3: Writing objects: .... \r
>
> only all smashed into one line of course, so only the most recent
> one is being displayed.
Looks good, although as Nicholas pointed out you might not know in
advanced how many steps there are.
So I still think that Nicholas' original point is valid is here, and
if you overwrite old progress bars with new ones then you may falsely
give the impression of "going backwards".
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Nicolas Pitre @ 2007-10-19 11:58 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Shawn O. Pearce, git
In-Reply-To: <20071019042930.GA16487@coredump.intra.peff.net>
On Fri, 19 Oct 2007, Jeff King wrote:
> On Thu, Oct 18, 2007 at 09:21:55PM -0700, Linus Torvalds wrote:
>
> > I'd love it, but the way our current SHA1 parser works, I don't think it
> > can really do it.
> >
> > Basically, we currently assume that a SHA1 expression always expands to a
> > *single* SHA1.
>
> Ah, right. I hadn't thought of that. While it would be a nice
> convenience feature, it's probably not worth the deep internal hackery
> that would be required.
What about a preprocessor that could match <1>@{<2>..<3>} in the
argument list and substitute that with <1>@{<2>}..<1>@{<3>} before it is
actually parsed?
Nicolas
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Dan McGee @ 2007-10-19 12:10 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019090400.GA8944@coredump.intra.peff.net>
On 10/19/07, Jeff King <peff@peff.net> wrote:
> When matching source and destination refs, we were failing
> to pull the 'force' parameter from wildcard respects (but
> not explicit ones) and attach it to the ref struct.
>
> This adds a test for explicit and wildcard refspecs; the
> latter fails without this patch.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> remote.c | 2 ++
> t/t5400-send-pack.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index b20e2be..170015a 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -762,6 +762,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
> hashcpy(dst_peer->new_sha1, src->new_sha1);
> }
> dst_peer->peer_ref = src;
> + if (pat)
> + dst_peer->force = pat->force;
> free_name:
> free(dst_name);
> }
> diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
> index 57c6397..2d0c07f 100755
> --- a/t/t5400-send-pack.sh
> +++ b/t/t5400-send-pack.sh
> @@ -123,4 +123,52 @@ test_expect_success \
> git-branch -a >branches && ! grep -q origin/master branches
> '
>
> +rewound_push_setup() {
> + rm -rf parent child &&
> + mkdir parent && cd parent &&
> + git-init && echo one >file && git-add file && git-commit -m one &&
> + echo two >file && git-commit -a -m two &&
> + cd .. &&
> + git-clone parent child && cd child && git-reset --hard HEAD^
> +}
> +
> +rewound_push_succeeded() {
> + cmp ../parent/.git/refs/heads/master .git/refs/heads/master
> +}
> +
> +rewound_push_failed() {
> + if rewound_push_succeeded
> + then
> + false
> + else
> + true
> + fi
> +}
> +
> +test_expect_success \
> + 'pushing explicit refspecs respects forcing' '
> + rewound_push_setup &&
> + if git-send-pack ../parent/.git refs/heads/master:refs/heads/master
> + then
> + false
> + else
> + true
> + fi && rewound_push_failed &&
> + git-send-pack ../parent/.git +refs/heads/master:refs/heads/master &&
> + rewound_push_succeeded
> +'
> +
> +test_expect_success \
> + 'pushing wildcard refspecs respects forcing' '
> + rewound_push_setup &&
> + if git-send-pack ../parent/.git refs/heads/*:refs/heads/*
> + then
> + false
> + else
> + true
> + fi && rewound_push_failed &&
> + git-send-pack ../parent/.git +refs/heads/*:refs/heads/* &&
> + rewound_push_succeeded
> +'
> +
> test_done
> --
> 1.5.3.4.1254.gc1ca9-dirty
>
Hmm. For some reason this passes with your test case, but not with my
original bash test script[1]. Did you try it with this?
-Dan
[1] http://www.toofishes.net/uploads/
^ 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