* Re: What's cooking in git/spearce.git (topics)
From: Steffen Prohaska @ 2007-10-22 15:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Shawn O. Pearce
In-Reply-To: <20071022063222.GS14735@spearce.org>
On Oct 22, 2007, at 8:32 AM, Shawn O. Pearce wrote:
> * sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits
> - push, send-pack: use same rules as git-rev-parse to resolve
> refspecs
> - add ref_cmp_full_short() comparing full ref name with a short name
> - push, send-pack: support pushing HEAD to real ref name
> - rev-parse: teach "git rev-parse --symbolic" to print the full ref
> name
> - add get_sha1_with_real_ref() returning full name of ref on demand
> - push, send-pack: fix test if remote branch exists for colon-less
> refspec
>
> I've briefly looked at this series and there's reasons why its not
> in next yet.
It's not ready for next. Especially the last patch in the list
changes the existing behaviour in a way that might be unexpected
by longtime git users. And maybe we even need for the 1.6 cycle
before we can change the behaviour of git push.
> Its actually something that I'm interested in seeing
> fixed as the current behavior of how git-push matches refs on the
> remote side is just plain nuts. I'll look at it further after I
> get ph/parseopt and cc/skip into next.
I planned to draw a conclusion from the discussion in
http://marc.info/?l=git&m=119286893014690&w=2
and send an updated proposal based on what I learnt. But
unfortunately I didn't have time yet.
My impression now is that the details of the behaviour of "git
push" are hard to understand and should be made more explicit.
Related tasks are currently encoded in the refspecs, but the
details are not always obvious right away:
- creation of new branches on the remote side.
- deletion of branches on the remote side.
- pushing of branches matching on local and remote side.
- pushing local branches explicitly to a different ref on the remote.
- save newbies from pushing to 'non-standard' location, that
is only push to heads and tags.
- but also allow to push to funny refs if you force git to
do this.
All this is related to the topic above, although its maybe too much
to be solved at once.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summarycontinued
From: Federico Mena Quintero @ 2007-10-22 15:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
On Mon, 2007-10-22 at 12:04 +0100, Johannes Schindelin wrote:
> <rationale>There is a good chance that git is not optimised for most
> people's daily workflows, as project maintainers seemed to be much more
> forthcoming with patches, and therefore maintainers' tasks are much more
> optimised than in other SCMs.</rationale>
The following are workflows that would be very useful for my cow-orkers
and project peers.
End-user workflows:
* Clone from another SCM (mostly svn). Make a local branch to implement
something in various commits. Rebase to the "latest upstream sources"
when you are done, and then do the equivalent to "svn dcommit" to upload
your final changes to the other SCM. The use case for this is to fix a
complicated bug in GNOME, which uses SVN.
* While you are doing that, produce a patchset that you can send to the
maintainers for review. I love "git-format-patch -n --thread --stdout >
foo", but it's pretty painful to have to 1. look up git-format-patch's
options in the man page (if you use --stdout, shouldn't -n and --thread
be turned on by default?); 2. import "foo" into Evolution to then be
able to edit the zeroth mail, and then be able to use Evo's SMTP
configuration to send out the mails while preserving the threading.
* Clone a git repository which has several interesting branches. Figure
out which branch you are interested in. Create a local branch based on
that; do your changes there. Keep your code up to date (rebase? when
to fetch / pull / etc?).
* You have a personal branch with a bunch of commits: a mess of "real
work", "remove debugging printf", "fix typo", etc. Reformat / reorder
those patches into something suitable for submission. [I just found out
about git rebase --interactive and it's *FANTASTIC* for this!]
Maintainer workflows:
* Start a personal project in git and publish it for others to clone.
Assume several possible setups: dumb web server with no git installed,
git installed but no git-daemon, git installed with git-daemon running.
I've found that publishing is not trivial at all; it's a rather
cumbersome multi-step process.
* Several of your contributors publish their own git repositories.
Integrate changes from them, or review them. This interesting because
you'll have to do a lot of navigation in repos with which you aren't
familiar, you'll have to use the merging and conflict resolution tools,
you'll have to maintain the signoffs, etc.
* Set up a public repository to which other people can push.
* Publish just some of your branches. Do that often, say, because you
have new work to show in each of those branches.
Federico
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Andreas Ericsson @ 2007-10-22 15:19 UTC (permalink / raw)
To: Scott Parish; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20071022143637.GP16291@srparish.net>
Scott Parish wrote:
> On Sun, Oct 21, 2007 at 10:59:01PM +0100, Johannes Schindelin wrote:
>
>> Earlier, we tried to find the git commands in several possible exec
>> dirs. Now, if all of these failed, try to find the git command in
>> PATH.
>
> I'm tempted to try a different approach. What if instead of looping
> and building up strings of all the different absolute paths we want
> to try we just prepend to PATH with the correct extra precedence,
> and then call execvp on the command we want?
>
That's how the original git --exec-dir feature got implemented. There's
even a nifty function for it in git.c; prepend_to_path(). It's a
provably workable solution.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-22 15:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221558230.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> If I were to suggest any improvements, it'd be to change the
>>>> semantics of git-pull to always update the local branches set up to
>>>> be merged with the remote tracking branches when they, prior to
>>>> fetching, pointed to the same commit, such that when
>>>>
>>>> $ git show-ref master
>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>>>>
>>>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
>>> In general, this should fail. Because you are expected to have local
>>> changes in the local branches.
>>
>> BS argument.
>
> Aha. So you want to make sure that the local branches are no longer
> "purely" local. And you want to stop updating them when unpushed changes
> are in the local branches.
>
To me, it's more along the lines of "let git help me not make the
mistake of hacking on a six-week old codebase when I've explicitly asked
it to merge these and those remote tracking branches into these and
those local branches". Not updating those branches when there *are*
changes on them is something users can understand and will probably also
appreciate, but the reason for not allowing even fast-forwards escape me.
> Seems I cannot help you.
>
Well, I knew that much from the start so I didn't ask you to, and since
you seem to fail to grasp what I had in mind, I'm sure you'd botch the
implementation anyway. Thanks for not quite offering though ;-)
I'm sure you'll review the patch though, and I'm equally sure I will
appreciate your technical comments rather a lot more than this current
bickering about a feature it seems I can't express clearly enough in words.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 15:00 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <471CB443.9070606@op5.se>
Hi,
On Mon, 22 Oct 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 22 Oct 2007, Andreas Ericsson wrote:
> >
> > > If I were to suggest any improvements, it'd be to change the
> > > semantics of git-pull to always update the local branches set up to
> > > be merged with the remote tracking branches when they, prior to
> > > fetching, pointed to the same commit, such that when
> > >
> > > $ git show-ref master
> > > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
> > > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
> > >
> > > refs/heads/master gets set to refs/remotes/origin/master post-fetch.
> >
> > In general, this should fail. Because you are expected to have local
> > changes in the local branches.
>
>
> BS argument.
Aha. So you want to make sure that the local branches are no longer
"purely" local. And you want to stop updating them when unpushed changes
are in the local branches.
Seems I cannot help you.
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Federico Mena Quintero @ 2007-10-22 14:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <471C586A.9030900@op5.se>
On Mon, 2007-10-22 at 09:59 +0200, Andreas Ericsson wrote:
> I doubt many people on this list regularly use git-blame but it's a
> command that's definitely non-trivial to script out using only the
> "proper" commands, and CVS/SVN users expect it to be there, so it's
> probably worth listing anyhow.
Hmmm, I don't really want to turn the "summary" thread into oodles of
sub-threads, but here goes :)
Personally I find git-blame *EXTREMELY* useful. The workflow is:
1. Bug #12345 for FooApp gets assigned to you.
2. git-svn clone fooapp's repository
3. git checkout -b my-bugfix-branch-for-12345
4. debug debug debug
5. "WTF? Who wrote this crappy code?"
6. git blame culprit-file.c
7. "Oh, it was $person with $commit_id... what were they thinking at the
time?"
8. git show $commit_id
9. "Oh, I see their intentions now... what was going on at that time?"
10. git log <date range around $commit_id>
11. etc.
Git-blame is very nice for code archaeology (long explanation at
http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00238.html).
> Similarly, it might be helpful to have help topics the gdb way, like
> "git help patches".
This would be simply fantastic. If those help topics suggested
workflows, I'd be delighted :) Feel free to poke me if you write up
some text; I'd love to help on this.
Federico
^ permalink raw reply
* deprecating colgit
From: martin f krafft @ 2007-10-22 14:23 UTC (permalink / raw)
To: git discussion list; +Cc: home in vcs discussion list
In-Reply-To: <20070906131525.GA7261@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
Dear list(s),
I would like to deprecate colgit [0] in favour of Joey Hess' mr [1],
which does everything colgit did, and much more.
0. http://lists.zerezo.com/git/msg629629.html
1. http://kitenet.net/~joey/code/mr/
If you have not seen mr, well, basically it manages collections of
repositories, like colgit aspired to do, but Joey made it
vcs-agnostic and much more robust. It's definitely worth checking
out.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"if a man treats life artistically, his brain is his heart."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Scott Parish @ 2007-10-22 14:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0710212256270.25221@racer.site>
On Sun, Oct 21, 2007 at 10:59:01PM +0100, Johannes Schindelin wrote:
> Earlier, we tried to find the git commands in several possible exec
> dirs. Now, if all of these failed, try to find the git command in
> PATH.
I'm tempted to try a different approach. What if instead of looping
and building up strings of all the different absolute paths we want
to try we just prepend to PATH with the correct extra precedence,
and then call execvp on the command we want?
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-22 14:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221445170.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>
>> If I were to suggest any improvements, it'd be to change the semantics of
>> git-pull to always update the local branches set up to be merged with the
>> remote tracking branches when they, prior to fetching, pointed to the same
>> commit, such that when
>>
>> $ git show-ref master
>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>>
>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
>
> In general, this should fail. Because you are expected to have local
> changes in the local branches.
BS argument. Git knows when I haven't got any changes on my local
branches, and it can be fairly safely assumed that when I feel like
making any, I'd like to make them off as fresh a tip as possible unless
I explicitly tell git otherwise.
Nice hint though. I'm working on a patch for it now but I've only looked
at it 15 minutes over lunch today, so it'll probably be a few days.
> What you describe suggests that you should
> not use the branch name "master" at all, but "origin/master".
>
No. I want the ability to commit locally without it affecting my
upstream tracking branches, but I also want to make sure that when I
want to work on some branch I don't frequently touch, git will make sure
it's kept up-to-speed with the branch I explicitly have told it to merge
with, without me having to remember if I was on that branch when I last
did git-pull (I might not have a network connection), and without having
to remember what I decided to call my locally-modifiable branch.
> That said, there is a pretty simple way to achieve what you want (even if
> it does not help the confusion you create between local and remote
> branches):
>
> git config --add remote.origin.fetch master:master
>
> Of course, when you checkout "master" and pull then, you'll get even more
> problems, _exactly_ because you muddled up the clear distinction between
> local and remote branches.
>
That's not what I want at all. I must have been unclear in my original
post. I'm talking about git doing automatically what every single user
I've ever talked to wants it to do, which is to maintain the state of
sync that the "local-and-modifiable" branches had with the
"local-non-modifiable-aka-remote-tracking" branches. Note that the state
of sync is more important to users than git never ever touching the
branches that they *could* have (but don't have) changes on.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] don't set-group-id on directories on apple
From: Scott Parish @ 2007-10-22 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710221234070.25221@racer.site>
On Mon, Oct 22, 2007 at 03:16:01PM +0100, Johannes Schindelin wrote:
> On Mon, 22 Oct 2007, Scott R Parish wrote:
>
> > "git init --shared=all" was failing because chmod was returning
> > EPERM.
>
> Not here. This is git version 1.5.3.rc4.1716.gc3498, and "uname -a" says
>
> Darwin michael-stirrats-mac-mini.local 8.10.0 Darwin Kernel Version
> 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC
> Power Macintosh powerpc
Darwin poplar.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386
> Is it possible that you have stricter permission settings?
This is a possibility, but i have no idea what that might be. I've
tried googling around without any luck (except for a post about
reading "mkdir(2)").
> Or that you try to re-initialise a repository that somebody else
> initialised originally?
No, this was a failure when running tests (t1301-shared-repo.sh)
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-22 14:29 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Steffen Prohaska, Federico Mena Quintero,
git
In-Reply-To: <8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com>
Jakub Narebski wrote:
> On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
> [...]
>>>>>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>>>>
>>>>>>> Maybe we could group commands into more categories?
>
>> Similarly, it might be helpful to have help topics the gdb way, like
>> "git help patches". It's one of those things that people have come to
>> expect from a software tool, so perhaps we should humor them? Given gits
>> "every help topic is a man-page" idiom, this shouldn't require any real
>> technical effort.
>>
>> Such topics should probably include
>> merge/merges/merging - overview of various ways of putting two lines of
>> development back together
>> patch/patches - how to create, send and apply
>> tags/branches/refs - what they are, why they're good, link to merging
>
> Very good idea. It is definitely something that can be worked on.
>
> By the way, what do you think about "spying" version of git, specially
> marked release which gathers statistics of porcelain used, with
> frequency of its use, and git-sendstats command added in this release?
>
I like it and I'd use it. What's more interesting is that I could
probably get my co-workers to do the same.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Federico Mena Quintero @ 2007-10-22 14:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710200035020.25221@racer.site>
On Sat, 2007-10-20 at 00:37 +0100, Johannes Schindelin wrote:
> FWIW try this:
>
> git<Space><Tab>
>
> or even better:
>
> git<Enter>
Hmm, this didn't work. I'm still using git 1.5.4.2 from the
stock openSUSE 10.3 packages --- did this get added in a newer version?
Federico
^ permalink raw reply
* Re: [PATCH] don't set-group-id on directories on apple
From: Johannes Schindelin @ 2007-10-22 14:16 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071022075459.GA1157@srparish.net>
Hi,
On Mon, 22 Oct 2007, Scott R Parish wrote:
> "git init --shared=all" was failing because chmod was returning
> EPERM.
Not here. This is git version 1.5.3.rc4.1716.gc3498, and "uname -a" says
Darwin michael-stirrats-mac-mini.local 8.10.0 Darwin Kernel Version
8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC
Power Macintosh powerpc
Is it possible that you have stricter permission settings? Or that you
try to re-initialise a repository that somebody else initialised
originally?
Ciao,
Dscho
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Karl Hasselström @ 2007-10-22 14:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Michael Witten, Shawn O. Pearce, git
In-Reply-To: <87ACA689-CBBD-4E6D-9BAD-B3BBA8391DB9@wincent.com>
On 2007-10-20 13:15:19 +0200, Wincent Colaiuta wrote:
> I think the issue here is that git-mv as it is currently implemented
> really conflates two things:
>
> 1. Renaming a file in the traditional "mv" sense
> 2. Staging the entire contents of the file in the index, ready or not
>
> So it's kind of like the command were called git-mv-and-add or git-
> rename-and-add. And given that the index as a staging area is such a
> central content in Git, users often want to have more control over
> what gets added to the index than that; ie. "I really just wanted to
> rename the file, and leave the staging of modifications to the
> content up to me".
I've come to that conclusion too while reading this thread. It would
make more sense for git-mv to, as others have already suggested, move
the file in the worktree and move the file in the index but _not_ add
workdir updates to the index. git-mv --cached would do only the index,
and not touch the worktree.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Karl Hasselström @ 2007-10-22 14:00 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Ari Entlich, Michael Witten, git
In-Reply-To: <20071020064003.GA30605@coredump.intra.peff.net>
On 2007-10-20 02:40:03 -0400, Jeff King wrote:
> Right. So the exact state you have in your index never actually
> existed in your working tree. But that's OK if:
> - the changes are trivial and obviously correct
> - you're not actually planning on _committing_ that, you just want
> to build the commit using the index
Or
- you plan to revisit the commit at a later time and verify that
it's OK
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <471C9B13.9080603@op5.se>
Hi,
On Mon, 22 Oct 2007, Andreas Ericsson wrote:
> If I were to suggest any improvements, it'd be to change the semantics of
> git-pull to always update the local branches set up to be merged with the
> remote tracking branches when they, prior to fetching, pointed to the same
> commit, such that when
>
> $ git show-ref master
> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>
> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
In general, this should fail. Because you are expected to have local
changes in the local branches. What you describe suggests that you should
not use the branch name "master" at all, but "origin/master".
That said, there is a pretty simple way to achieve what you want (even if
it does not help the confusion you create between local and remote
branches):
git config --add remote.origin.fetch master:master
Of course, when you checkout "master" and pull then, you'll get even more
problems, _exactly_ because you muddled up the clear distinction between
local and remote branches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Pierre Habouzit @ 2007-10-22 13:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <471C950E.40702@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Mon, Oct 22, 2007 at 12:18:22PM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >On Mon, Oct 22, 2007 at 11:35:30AM +0000, Johannes Sixt wrote:
> >>Pierre Habouzit schrieb:
> >>>On Mon, Oct 22, 2007 at 08:53:36AM +0000, Johannes Sixt wrote:
> >>>>Pierre Habouzit schrieb:
> >>>>>+say_color () {
> >>>>>+ [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
> >>>>>+ shift
> >>>>>+ echo "* $*"
> >>>>>+ tput op
> ^^^^^^^^
> I am talking about this line.
Oooh, good catch :P it should be guarded by a [ "$nocolor" = 0 ]
indeed :P (or use your solution).
> >>>>>+}
> >>I wanted to point out that if tput is not available, the second
> >>invocation will leave "tput: command not found" behind on stderr.
> >>Therefore, I proposed to make the definition of say_color() different
> >>depending on whether $color is set or not. Then you don't need to test
> >>for $color twice inside the function.
> > Right we can do that. I'll try to rework the patch. and no it
> >shouldn't leave tput: command not found as I 2>/dev/null and I think the
> >shell doesn't print that in that case. At least my zsh doesn't.
>
> There is no 2>/dev/null. Am I missing something?
I was.
--
·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: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Ericsson, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com>
Hi,
On Mon, 22 Oct 2007, Jakub Narebski wrote:
> On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
> [...]
> >>>>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>>>>
> >>>>>> Maybe we could group commands into more categories?
>
> > Similarly, it might be helpful to have help topics the gdb way, like
> > "git help patches". It's one of those things that people have come to
> > expect from a software tool, so perhaps we should humor them? Given gits
> > "every help topic is a man-page" idiom, this shouldn't require any real
> > technical effort.
> >
> > Such topics should probably include
> > merge/merges/merging - overview of various ways of putting two lines of
> > development back together
> > patch/patches - how to create, send and apply
> > tags/branches/refs - what they are, why they're good, link to merging
>
> Very good idea. It is definitely something that can be worked on.
>
> By the way, what do you think about "spying" version of git, specially
> marked release which gathers statistics of porcelain used, with
> frequency of its use, and git-sendstats command added in this release?
I like Wincent's approach, scanning .bash_history.
Ciao,
Dscho
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter error
From: Johannes Schindelin @ 2007-10-22 13:44 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710221337.50730.wielemak@science.uva.nl>
Hi,
On Mon, 22 Oct 2007, Jan Wielemaker wrote:
> On Monday 22 October 2007 13:20, Johannes Schindelin wrote:
>
> > The subdirectory filter does not look kindly upon a history where some
> > commits lack the subdirectory in question. However, this should work:
> >
> > git filter-branch --subdirectory--filter RDF 95807fe01..HEAD
>
> Thanks, but ... hmmm.
>
> $ git filter-branch --subdirectory-filter RDF
> 95807fe01c39d3092e3ac3a98061711323154d77..HEAD
> Rewrite 0a43c802dd60f53d48136a32526a4b2a5f0d43e5 (1/11)fatal: Not a valid
> object name 0a43c802dd60f53d48136a32526a4b2a5f0d43e5:RDF
> Could not initialize the index
I suspect again that this commit does not contain the RDF/ subdirectory.
> This started as a big project with a lot of history in CVS, including
> moved (read deleted and re-created) files. This was moved to SVN and
> from there immediately to GIT. In GIT lots of things have been renamed.
> The RDF directory was created quite recent in the project and things
> from various subdirectories were moved there.
>
> Is there something that might be worth a try or should we go the simple
> way: keeping the old combined repo for later reference and create two
> new ones from fresh files?
It sure sounds pretty tricky. (IOW I'm probably unable to help more...)
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-22 13:38 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com>
Hi,
On Mon, 22 Oct 2007, Wincent Colaiuta wrote:
> El 22/10/2007, a las 13:04, Johannes Schindelin escribi?:
>
> > So once again, what operations involving git do people use regularly?
>
> Here are my top ten commands, sorted by the number of times they appear
> in my ~/.bash_history:
Thanks. That's a really good idea. I did the same, and it turns out that
my list was wrong:
68 log
50 fetch
36 show
33 diff
19 grep
19 commit
14 ps (my alias which runs -p status)
10 config
8 rebase
8 push
Everybody who wants to find out the same: this is how I did it:
cat .bash_history |
tr ";" "\\n" |
sed -n "s/^ *git[- ]\([^ ]*\).*$/\1/p" |
sort |
uniq -c |
sort -r -n
One thing that I realised by looking at my list: It probably makes more
sense teaching people about "fetch" in the beginning, teach other parts
about git, and only then "push".
We tend to teach people about "fetch" and "push" at the same time, but
this is not consistent with any workflow.
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Nguyen Thai Ngoc Duy @ 2007-10-22 13:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
On 10/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So once again, what operations involving git do people use regularly?
All operations in my laptop since May:
621 git log
614 git diff
510 git status
378 git grep
203 git checkout
166 git add
159 git commit
106 git fetch
87 git branch
61 git help
55 git am
49 git ls-files
48 git format-patch
46 git show
46 git reset
46 git clone
44 git cherry-pick
42 git merge
36 git apply
26 git cherry
25 git push
25 git describe
24 git rev-list
20 git rebase
18 git pull
17 gitview
16 git shortlog
15 git revert
15 git cat-file
12 git name-rev
11 git update-index
11 git ls-tree
11 git count-objects
10 git tag
9 git send-email
9 git rev-parse
7 git svn
7 git read-tree
6 git repack
6 git fsck
4 git init
4 git clean
3 git rm
3 git gc
2 git submodule
2 git prune
2 git ls
2 gitk
2 git gui
2 git config
1 git mailinfo
1 git lost-found
--
Duy
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: David Symonds @ 2007-10-22 13:33 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Andreas Ericsson, Jakub Narebski,
Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com>
On 22/10/2007, Wincent Colaiuta <win@wincent.com> wrote:
> El 22/10/2007, a las 13:04, Johannes Schindelin escribió:
>
> > So once again, what operations involving git do people use regularly?
>
> Here are my top ten commands, sorted by the number of times they
> appear in my ~/.bash_history:
Sounds like a good idea. Here's mine (my .bash_history is limited to
500 commands, though):
$ cat ~/.bash_history | grep ^git | cut -c5- | cut -d' ' -f1 | sort |
uniq -c | sort -nr | head -10
64 status
37 diff
23 push
13 checkout
12 add
9 log
9 commit
8 rebase
8 branch
5 count-objects
Dave.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Wincent Colaiuta @ 2007-10-22 13:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Jakub Narebski, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
El 22/10/2007, a las 13:04, Johannes Schindelin escribió:
> So once again, what operations involving git do people use regularly?
Here are my top ten commands, sorted by the number of times they
appear in my ~/.bash_history:
533 status
342 diff
252 commit
234 add
123 checkout
116 log
106 push
97 config
83 show
83 branch
Not very scientific, but it gives a rough idea of how one Git newbie
(using it for several months) with a very basic workflow uses Git.
Cheers,
Wincent
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-22 13:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, david, git
In-Reply-To: <Pine.LNX.4.64.0710221125350.25221@racer.site>
On Oct 22, 2007, at 12:29 PM, Johannes Schindelin wrote:
>
> On Mon, 22 Oct 2007, Steffen Prohaska wrote:
>
>> .gitattributes is first looked for in the working directory, and
>> if not
>> there, .gitattributes is read from the index.
>
> Of course we could change that to do it the other way round. But this
> would contradict expectations when you edit .gitattributes and then
> checkout single files without having git-add'ed .gitattributes first.
>
> The biggest problem in your setup, however, is not
> if .gitattributes is
> read from the index or the working directory. The biggest problem
> is that
> files are not touched when their contents have not changed.
>
> IOW if you have .gitattributes in the to-be-checked-out branch
> which say
> that README is crlf, and in the current branch it is not, and README's
> _contents_ are identical in both branches, a "git checkout
> <that-other-branch>" will not rewrite README, and consequently not
> change
> the working copy to crlf.
Exactly. The order of reading .gitattributes from the working
directory or the index doesn't matter. The current mechanism
has a more fundamental deficiency.
Changes of.gitattributes can influence how the same content
is checked out to the work tree. If .gitattributes change the
checkout may need to be updated, even if the real content did
not change.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-22 12:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710221156540.25221@racer.site>
Johannes Schindelin wrote:
> So once again, what operations involving git do people use regularly?
>
diff
qgit
commit
fetch
rebase
merge
status
push
cherry-pick
grep
bisect
add
show-ref
If I were to suggest any improvements, it'd be to change the semantics
of git-pull to always update the local branches set up to be merged with
the remote tracking branches when they, prior to fetching, pointed to
the same commit, such that when
$ git show-ref master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
refs/heads/master gets set to refs/remotes/origin/master post-fetch.
This would save me from this command sequence, which I currently have to
do for git.
git fetch
git checkout next
git merge spearce/next
git checkout master
git merge spearce/master
git checkout maint
git merge spearce/maint
git checkout pu
git reset --hard spearce/pu
<rinse and repeat for every tracked branch>
git could definitely help here. I want the local branches to be
up-to-date with the remote ones, because I frequently run diffs against
the various branches to see if anything that I should be aware of has
changed, and just as frequently I forget to add that 'origin/' prefix,
which means I *might* be looking at old code.
I usually do that on internal projects, where we have "master", "next",
"testing", and "stable" branches for pretty much every repo. We have 54
git repos. The typing adds up. This is also one of the most frequent
causes of confusion for my (even) less git-savvy co-workers. The
argument usually goes like this:
"Umm... Peter, why did you commit your fix on top of 7 weeks old code?"
"Oh? I did git-pull first, just as you said, so it should have been the
latest, shouldn't it?"
"Well, what branch were you on when you pulled?"
"Err.. does that matter? I didn't have any local modifications on the
branch when I pulled, so it should have just updated it."
What's happened prior to such an argument is usually this:
next or master is inevitably checked out. The user does git-pull to get
up to date. They then change branch and get down to business with
rebasing, merging and editing. When it's time to push, git tells them
"not a strict subset. use git-pull!", and they do, and sometimes it
fails, and I have a hard time explaining why since I really don't see a
reason for *not* updating all "to-merge" branches when they point to the
same commit as their tracking-branch before the pull.
Patch to follow (at some point), although it's likely to make git-pull a
built-in since I have no idea how to maintain coupled lists in shell.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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