* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-21 6:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Daniel Barkalow, Thomas Rast, git
In-Reply-To: <20091021030608.GA18997@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> So that's ten days of #git. I left out a bunch of duplications (most
> were "pull == fetch", "pull == update" and "pull to update
> non-checked-out branch").
Interesting; this shows that people who do not understand what "pull" does
expect different behaviour from "pull", use the word "pull" to express
what they want to happen, expect other people interpret the word to mean
the way they think it does. At the same time, judging from different
behaviour expected by these people, push/pull asymmetry does not seem to
have much to do with the confusion. If the verb used by people who know
git to call this operation were "distim", these people would also say
"distim" and expect different things from it. I would foresee exactly the
same problem if the verb were "update" for that matter.
It is just natural, as everybody learns a new language by listening how
others talk and by imitating them.
Another thing I noticed while lurning on the #git channel for the past few
days is that too much flexibility actually hurts new people. They do not
want flexibility, but want to follow a set recipe. It just overwhelms to
get too much flexibility upfront without enough guidance.
And there are too much historical flexibility that remain merely for
historical reasons. We more or less killed the concept of separate object
store and $GIT_DIR (i.e.one objects/ directory shared between more than
one .git/ directories) when we made receive-pack aware of alternate
repository information---it used to be that objects/ directory did not
belong to a single set of refs/ hierarchy, but now it does and the
receiving end of "git push" uses that knowledge to tell the sender what
not to send in order to minimize the transfer. We will be gradually
killing other kinds of historical flexibility that do not buy much in
practice anymore, and that would reduce the issue of overwhelming
flexibility.
For example, I am in favor of deprecating the "pull $there $src:$dst"
notation. Before we standardized on the separate remote layout, it was
sometimes handy to be able to use $dst that is a local branch, but these
days, especially when repository $there has remote.$there.fetch mapping
configured so that we can compute from $src what remote tracking branch we
should store the fetched commit, the flexibility is more confusing than it
is useful. "pull $there $src" (and "pull $there $src1 $src2" to build an
octopus) should stay, but even there, it probably is a good idea for these
notations to start updating remote tracking branches for $src ($src1 and
$src2 in the octopus case) if the repository is configured to track them
anyway, to match what "pull $there" that uses the default configuration
does.
I am actually even Ok, at least in the long run (like in 3 years), if we
were to deprecate the refspecs with colon given on the command line to
"pull" and "fetch" altogether [*1*]. The rule will become "if you are
going to use tracking branches to store what you fetch, you _must_ always
have the tracking mapping defined in remote.$there.fetch configuration,
and the location where one particular branch from the remote is stored is
always determined by that mapping." It robs us the flexibility to fetch
my 'next' and store it to your 'next' branch today and to your 'mext'
branch tomorrow, and instead you would need to first fetch and then do an
explicit "git branch mext origin/next" if you really want to do so, but I
think the flexibility outlived its usefulness --- the primary value of
these kinds of flexibility is to experiment with various workflows and UI
concepts they allow, but I think we have gained enough experience to start
judging what works (and is useful) and what doesn't (and is Ok to make it
much more cumbersome to make or even impossible to do).
[Footnote]
*1* Except perhaps when deleting branches from the remote with "push", but
even there we _could_ force people to do a deleting push separate from
normal push and say "push --delete $there $this $and $that".
^ permalink raw reply
* Re: ident hash usage question
From: Daniel Barkalow @ 2009-10-21 5:35 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <76c5b8580910201649i76d14f8bod9a84afa6ea6bbb0@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4248 bytes --]
On Tue, 20 Oct 2009, Eugene Sajine wrote:
> > I am not sure what you mean by "static linking" anymore. Usually the word
> > means that everything you tell the linker to link to the executable is
> > linked, together with objects from libraries. The resulting executable is
> > usable on its own and it does not change behaviour regardless of which
> > version of dynamic libraries you depend on happen to be installed on the
> > target system (because by definition a statically linked executable does
> > not depend on dynamic libraries---that is the whole point of static
> > linking).
> >
>
> There seems to be no misunderstanding in the static linking - i meant
> the same thing. But let me put an example:
>
> I have a program.exe
>
> This program.exe is built basing on two statically linked libraries
> lib1.lib and lib2.lib
>
> I'm not developing any of those libraries, but only my own code of the
> program.exe
>
> Now, somebody changed 2 files in lib1.lib and 5 files in lib2.lib. But
> i don't know that they are changed because it is different CVS module
> or because I'm building against latest released libs or for whatever
> reason...
>
> When i rebuild my program the build supposed to pick up changes from
> the libraries I'm using and relink, that will include 7 changed obj
> files.
>
> How can i say which exactly files are changed in my new version of
> executable comparing to the previous version?
As Nanako points out, you want a version string from each library,
probably with the name of the library in the symbol. So:
static char *lib1_version = "" VERSION_STRING
in lib1/version.cc.
> Currently they can take a look at the revision number of every
> particular file included into the executable, which is put there by
> CVS and compare it with the production. If the version is different,
> then you know which files are changed and you can get diffs on them...
> They also have file path and date and other stuff expanded...
Once you've got the version strings from each of the components, and
you've got the repository for each library, you can compare the version in
the string with other versions, and that one hash expands to the hashes
for all of the files, including things like the Makefile that don't
actually become object files but affect them.
You can also do things like: when you build an executable, write it as a
blob to the repository and make a tag (actually, a note will be
better, but that's newer than I've done this) pointing to it that lists
everything used to build it. If you encounter the executable again later,
it'll have the same hash, and git can find the tag with the other
information.
I've actually done something where I tagged the main tree and a few
libraries with matching tags, built the executable with a 20-byte
sequence of zeros, put it into the repository, then wrote its sha1 to
those 20 bytes, and tagged the executable with a tag based on the source
tag. Then I put it on a microcontroller, sealed it in epoxy, mixed it with
other devices with different firmware revisions, and sent it out. When a
device had a problem, I could ask it for those 20 bytes, ask git for the
tag that pointed to those 20 bytes, and check out exactly the source used
to build it.
> Please note, my personal goal is *to prove that git can do that
> better*, with less intrusion into the code sources, not other way
> around.So, while keeping the info they want to have they might get
> some benefits of git. Although, i understand that there might be no
> cure for this state already, you can tell me that and I will close the
> topic, but I just keep hoping;)
You're not going to be able to avoid having different tracking things in
the source, but git does give you the major advantage that you can have
the build system produce one hash that identifies every single file in the
project, rather than having to have each file identify itself (and
probably overlook files that don't directly produce object code). It's a
big help the day you're trying to figure out if an executable came from
before or after someone's commit to change the compiler options, and it's
fewer strings than you need with CVS.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 4:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Sean Estabrooks, Thomas Rast, git
In-Reply-To: <20091021031528.GB18997@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1172 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.20 20:55:25 -0400, Daniel Barkalow wrote:
> > Maybe it should be fine to do:
> >
> > $ git fetch long-url-here master:temp
> > $ git merge temp
> > $ git checkout other-branch-that-also-needs-it
> > $ git merge temp
> >
> > But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
>
> One (maybe important) difference there is that the "pull" gets you:
>
> Merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
>
> Even with "master:tmp". But with fetch+merge (storing in refs/remotes):
>
> Merge remote branch 'tmp'
It would be nice to improve that in general, I think. You may fetch before
merging in order to check out what you're getting, and then lose
FETCH_HEAD (or have not specified the branch), and you have to contact the
remote server again if you want the message with its url.
> As a minor side-effect, having the "tmp" ref makes re-running the pull
> (for whatever reason) cheaper, as without it, the fetch step would
> possibly re-fetch the whole stuff (not reachable through any local ref).
Only if the merge failed, but yes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-21 4:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Thomas Rast, git
In-Reply-To: <20091021030608.GA18997@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 11651 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:
> > But I don't really know; are there IRC logs you can quote or reference
> > with people making the mistake you're trying to help them avoid?
>
> "git pull" is kind of a jack of all trades WRT user errors, so I'll just
> pick up examples of all kinds, this might get long...
>
> [If you read this and find out that you're quoted/referenced here: I
> don't mean to blame or embarrass you, or to point out that you're stupid
> or whatever. Quite contrary, I just want to show how git's pull UI _might_
> be responsible for your mistakes. The comments I made are purely my,
> possibly biased, reaction to what happened.]
>
> That said, here we go:
>
> 1) Unexpected fast-forward even with --no-ff
>
> "git pull --no-ff abc:abc" with "abc" being checked out.
>
> As pull explicitly allows fetches into the checked out branch head, this
> first fast-forwards abc, and updates the working tree/index. And then
> the --no-ff merge is a no-op.
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080
> (Should be a catchable special case, and the special --update-head-ok
> handling of "git pull" is from times where git didn't have remote
> tracking branches. I'd argue that that support should be dropped or at
> least disabled when you're using the modern setup, might be kept for
> oldtimers still using .git/remotes/*. Dunno...)
Yup, I think it would be good to ditch --update-head-ok and simplify the
code; I also think it would be nice to prohibit fetching into refs/heads/*
entirely, but there might be advanced users who actually want to do that.
In this case, "git fetch" has already done something the user didn't want,
and the pull-specific portion doesn't actually do anything at all.
> 2) "git pull" taken as "reset --hard"
> git checkout -b foo; git pull origin bar
>
> The user actually just wanted to look at things and thus was ok with:
> git fetch origin; git checkout origin/bar
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807
> (user seemed to be so inclined to use "pull" that he initially didn't
> even realize that he didn't want to merge when I asked whether that's
> what he wants)
I think that's a case where the user has been discouraged from using
detached HEAD, and is using "pull" instead of "fetch" in order to update
the junk branch he doesn't actually want. If you don't know you don't need
a local branch, and you branch off of a common ancestor, "pull" does
actually do something you want that "fetch" doesn't.
> 3) User expects "pull" to update all branch heads that have a configured
> upstream
>
> 08:31 dimsuz hi guys! suppose i'm currently on master. then run git
> fetch. which delivers updates to master and other
> branches. I don't merge anything, but do checkout some
> branch (which is not master). Question: will these new
> updates get into this branch automatically after i check
> it out? question2: will branch master contain those
> updates when i ckeck it out later?
> 08:32 Circuitsoft dimsuz. After a fetch, no.
> 08:33 Circuitsoft However, if you pull, any branches that were set
> up as local tracking branches will get updated.
> 08:33 Circuitsoft Otherwise, only remote tracking branches will be
> updated.
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
> (No idea about that one, have seen that once before, but it's definitely
> not even remotely as common as the others)
I'd guess that's due to having local branches with no local changes, just
to avoid detached HEAD, and therefore thinking it's normal to have a bunch
of local branches that could be updated without merges. But I'm on a crazy
"everybody really wants detached HEAD and is needlessly scared" kick, and
I'm probably reading too much into it.
> 4) User expects "pull" to create branches
>
> 07:25 fynn Hey, I just pulled a branch from remote, and I don't see
> it in "git branch"
> 07:25 doener fynn: if you "pull" that means "fetch this and merge it
> to what I have checked out"
> 07:25 fynn doener: hm, I just did "git pull" and it showed the new
> branch
> 07:26 fynn but I don't see it in my branches...
> 07:26 fynn doener: should I create that branch as a tracking branch
> first?
> 07:26 doener fynn: you're looking at "git branch -r" or "git branch
> -a", right?
> 07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
> local.
> 07:26 doener fynn: the "git fetch" should have created a remote
> tracking branch, as usual, not a local branch head
> (which would be shown by just "git branch")
> 07:27 fynn doener: OK, what should I do to create it locally then?
> 07:28 doener fynn: just the usual "git branch foo origin/foo", or to
> checkout at the same time: "git checkout -b foo
> origin/foo" or "git checkout -t origin/foo" (shortcut)
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
> (Note how my "fetch this and merge it" is actually inaccurate for just
> "git pull", there is no "this" and that case. I took "pulled a branch"
> to mean that he did "git pull <remote> <branch>", which wouldn't have
> created/update the remote tracking branch [or did patches for that go
> in? I lost track...])
That sounds like a real converse of "push", including creating like-named
local branches. Or, perhaps, this is someone expecting that "pull" is like
"clone" in creating an initial local branch with the name and value of a
specified remote branch.
> 4b) User expects pull to create a branch head
>
> 09:58 araujo git pull origin <new_branch>
> 09:58 araujo will get me the new branch from repo right?
> 10:00 charon araujo: no, that will fetch *and merge* that branch
> 10:00 araujo charon, how to just pull?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152
> (Note how he asked "how to just pull?", even after being told that pull
> isn't what he wants)
That's got to be hg usage. He knows the command isn't "pull", but he's
stuck with the operation it performs being pulling. Or maybe he's thinking
that the operation is pulling, and the command needs different arguments
to not merge.
> 5) User possibly expecting "pull" to be able to act as "reset --hard"
>
> 21:01 aidan What do I do about this: html/config/core.php: needs
> update
> 21:02 aidan git pull (gives that)
> 21:02 Ilari aidan: You have uncommitted changes to that file...
> 21:15 aidan Ilari: how can I just pull master and overwrite any
> changes?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
> (I'm not sure about that one, "overwrite any changes" might mean "drop
> uncommitted changes and merge" or "just get me the remote's state,
> dropping my commits and uncommitted changes". Most of the time I've seen
> similar requests, the user wanted the latter).
So I think that's a desire for "git checkout ." first of all (with the
assumption that the content without modifications has to come from
somewhere remote). I don't know what's up with people not wanting to save
their commits, though.
> 6) User says "pull" but probably means "fetch"
>
> 14:08 Alien_Freak once I have a clone of a repo I know you can do
> a checkout tag but is there anyway to pull just
> the tag?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
> (There was no answer, thus it's hard to tell, but I guess he wanted
> something like:
> git init; git fetch --no-tags url tag <tag>; git checkout <tag>
> At least I'm quite sure he didn't mean "pull" as in "git pull")
I don't know; you can actually do:
$ git init; git pull --no-tags <url> tag <tag>
It updates the master branch and working directory from (nothing) to the
fetched tag.
> 7) User expecting "pull" to just do fast-forwards (or so)
>
> 13:18 ohadlevy I'm getting a merge commit message after each
> time i do git pull, i didnt have it before,
> where should I look?
> 13:20 charon ohadlevy: pull merges; you may just have hit lucky so
> far, and always had a fast-forward merge
> 13:20 ohadlevy charon: any way I could avoid these commits?
> just rebasing? its a pure RO repo
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579
> (Apparently, user was tricked by the fast-forward behaviour he
> experienced earlier. I don't see any solution to this, except for
> defaulting to fast-forward-only and requiring a --merge flag (which
> might imply --no-ff), but I'm likely influenced by the "git update"
> stuff here)
Again, sounds like the user does want to update local branch state, if
there is any. Probably doesn't want a local branch, what with being
confused at the possibility of having history that's not from the remote.
> 8) "reset --hard" again
>
> 20:10 roger_padactor i commited then did a pull how do i get back to
> my commit. the pull over wrote the files
> 20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
> reset to latest commit
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
> (Someone being told that pull is fetch + reset --hard is actually new to
> me. Only saw that as an expectation previously.)
That's odd. How could you not notice that it doesn't actually do that,
even if you try to get it to?
> 9) More "git pull <remote> A:A"
>
> 19:10 _hp_ another question, how do I add the remote branch to
> track so I don't have to constantly do git pull origin
> masterA:masterA ?
> 19:11 Ilari _hp_: Don't use that src:dest with pull!
> (discussion died)
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427
Yup. Oh, and it strikes me that this user must have never made any
commits, because that would give an error (not fast forward) on the fetch
part.
> 10) "pull" mistaken for "cvs update"
>
> 07:25 Avrem how do I use "git pull" to do something like what "cvs
> update" does ?
> 07:25 Avrem which is, replaces files I've deleted
> 07:25 Avrem from that from the central repository
> 07:30 omega I'm not sure, but can't you git checkout <deleted files>
> to get them back?
>
> http://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545
> (This adds a new twist to the "scm update" stuff, although svn/hg don't
> seem to have "restore individual files" in their "update" command, so
> this might be cvs-only. But it's so long since I used cvs, I don't even
> know whether this is correct. But it somehow got me thinking about how
> "update" is actually also "downgrade" in svn/hg, something git does via
> "checkout" [which happens to make more sense to me]. And I think it
> shows how "git pull" is taken to mean "update", even when ignoring the
> special behaviour described here. It's not taken to mean "merge this",
> but just "update to upstream").
"cvs update" can definitely discard uncommitted changes, according to the
--help text.
Actually, I wonder if the right formula is update = fetch + checkout.
There are a lot of people (IMHO) want "git fetch origin; git checkout
origin/master", and I think their first idea is "git update", but that
doesn't exist, and they find "pull" as the closest thing.
> So that's ten days of #git. I left out a bunch of duplications (most
> were "pull == fetch", "pull == update" and "pull to update
> non-checked-out branch").
Very interesting. I feel like this is a new thing since I last spent much
time on IRC, when it was all people pushing into non-bare repositories.
Thanks for taking the time to collect this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Björn Steinbrink @ 2009-10-21 3:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Sean Estabrooks, Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202044150.14365@iabervon.org>
On 2009.10.20 20:55:25 -0400, Daniel Barkalow wrote:
> Maybe it should be fine to do:
>
> $ git fetch long-url-here master:temp
> $ git merge temp
> $ git checkout other-branch-that-also-needs-it
> $ git merge temp
>
> But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
One (maybe important) difference there is that the "pull" gets you:
Merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
Even with "master:tmp". But with fetch+merge (storing in refs/remotes):
Merge remote branch 'tmp'
As a minor side-effect, having the "tmp" ref makes re-running the pull
(for whatever reason) cheaper, as without it, the fetch step would
possibly re-fetch the whole stuff (not reachable through any local ref).
Björn, undecided...
^ permalink raw reply
* Re: ident hash usage question
From: Nanako Shiraishi @ 2009-10-21 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, Alex Riesen, git
In-Reply-To: <7vbpk1lmvl.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> If your product ships as one main executable _dynamically_ linked with two
> dynamic libraries, and all three components are built from the source
> material under your source control, obviously you would need to make sure
> that the above version.o or some equivalent of what embeds output from
> "git describe HEAD" are linked to the main executable and to the two
> libraries, but the idea is the same.
Doesn't the above strategy also apply to the case where the
libraries are linked statically, too? You get the version
string from the main program and two version strings from the
libraries embedded in the final product.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Björn Steinbrink @ 2009-10-21 3:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910201912390.14365@iabervon.org>
On 2009.10.20 19:56:01 -0400, Daniel Barkalow wrote:
> But I don't really know; are there IRC logs you can quote or reference
> with people making the mistake you're trying to help them avoid?
"git pull" is kind of a jack of all trades WRT user errors, so I'll just
pick up examples of all kinds, this might get long...
[If you read this and find out that you're quoted/referenced here: I
don't mean to blame or embarrass you, or to point out that you're stupid
or whatever. Quite contrary, I just want to show how git's pull UI _might_
be responsible for your mistakes. The comments I made are purely my,
possibly biased, reaction to what happened.]
That said, here we go:
1) Unexpected fast-forward even with --no-ff
"git pull --no-ff abc:abc" with "abc" being checked out.
As pull explicitly allows fetches into the checked out branch head, this
first fast-forwards abc, and updates the working tree/index. And then
the --no-ff merge is a no-op.
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l2080
(Should be a catchable special case, and the special --update-head-ok
handling of "git pull" is from times where git didn't have remote
tracking branches. I'd argue that that support should be dropped or at
least disabled when you're using the modern setup, might be kept for
oldtimers still using .git/remotes/*. Dunno...)
2) "git pull" taken as "reset --hard"
git checkout -b foo; git pull origin bar
The user actually just wanted to look at things and thus was ok with:
git fetch origin; git checkout origin/bar
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l1807
(user seemed to be so inclined to use "pull" that he initially didn't
even realize that he didn't want to merge when I asked whether that's
what he wants)
3) User expects "pull" to update all branch heads that have a configured
upstream
08:31 dimsuz hi guys! suppose i'm currently on master. then run git
fetch. which delivers updates to master and other
branches. I don't merge anything, but do checkout some
branch (which is not master). Question: will these new
updates get into this branch automatically after i check
it out? question2: will branch master contain those
updates when i ckeck it out later?
08:32 Circuitsoft dimsuz. After a fetch, no.
08:33 Circuitsoft However, if you pull, any branches that were set
up as local tracking branches will get updated.
08:33 Circuitsoft Otherwise, only remote tracking branches will be
updated.
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
(No idea about that one, have seen that once before, but it's definitely
not even remotely as common as the others)
4) User expects "pull" to create branches
07:25 fynn Hey, I just pulled a branch from remote, and I don't see
it in "git branch"
07:25 doener fynn: if you "pull" that means "fetch this and merge it
to what I have checked out"
07:25 fynn doener: hm, I just did "git pull" and it showed the new
branch
07:26 fynn but I don't see it in my branches...
07:26 fynn doener: should I create that branch as a tracking branch
first?
07:26 doener fynn: you're looking at "git branch -r" or "git branch
-a", right?
07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
local.
07:26 doener fynn: the "git fetch" should have created a remote
tracking branch, as usual, not a local branch head
(which would be shown by just "git branch")
07:27 fynn doener: OK, what should I do to create it locally then?
07:28 doener fynn: just the usual "git branch foo origin/foo", or to
checkout at the same time: "git checkout -b foo
origin/foo" or "git checkout -t origin/foo" (shortcut)
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
(Note how my "fetch this and merge it" is actually inaccurate for just
"git pull", there is no "this" and that case. I took "pulled a branch"
to mean that he did "git pull <remote> <branch>", which wouldn't have
created/update the remote tracking branch [or did patches for that go
in? I lost track...])
4b) User expects pull to create a branch head
09:58 araujo git pull origin <new_branch>
09:58 araujo will get me the new branch from repo right?
10:00 charon araujo: no, that will fetch *and merge* that branch
10:00 araujo charon, how to just pull?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l1152
(Note how he asked "how to just pull?", even after being told that pull
isn't what he wants)
5) User possibly expecting "pull" to be able to act as "reset --hard"
21:01 aidan What do I do about this: html/config/core.php: needs
update
21:02 aidan git pull (gives that)
21:02 Ilari aidan: You have uncommitted changes to that file...
21:15 aidan Ilari: how can I just pull master and overwrite any
changes?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
(I'm not sure about that one, "overwrite any changes" might mean "drop
uncommitted changes and merge" or "just get me the remote's state,
dropping my commits and uncommitted changes". Most of the time I've seen
similar requests, the user wanted the latter).
6) User says "pull" but probably means "fetch"
14:08 Alien_Freak once I have a clone of a repo I know you can do
a checkout tag but is there anyway to pull just
the tag?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
(There was no answer, thus it's hard to tell, but I guess he wanted
something like:
git init; git fetch --no-tags url tag <tag>; git checkout <tag>
At least I'm quite sure he didn't mean "pull" as in "git pull")
7) User expecting "pull" to just do fast-forwards (or so)
13:18 ohadlevy I'm getting a merge commit message after each
time i do git pull, i didnt have it before,
where should I look?
13:20 charon ohadlevy: pull merges; you may just have hit lucky so
far, and always had a fast-forward merge
13:20 ohadlevy charon: any way I could avoid these commits?
just rebasing? its a pure RO repo
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1579
(Apparently, user was tricked by the fast-forward behaviour he
experienced earlier. I don't see any solution to this, except for
defaulting to fast-forward-only and requiring a --merge flag (which
might imply --no-ff), but I'm likely influenced by the "git update"
stuff here)
8) "reset --hard" again
20:10 roger_padactor i commited then did a pull how do i get back to
my commit. the pull over wrote the files
20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
reset to latest commit
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
(Someone being told that pull is fetch + reset --hard is actually new to
me. Only saw that as an expectation previously.)
9) More "git pull <remote> A:A"
19:10 _hp_ another question, how do I add the remote branch to
track so I don't have to constantly do git pull origin
masterA:masterA ?
19:11 Ilari _hp_: Don't use that src:dest with pull!
(discussion died)
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-12#l2427
10) "pull" mistaken for "cvs update"
07:25 Avrem how do I use "git pull" to do something like what "cvs
update" does ?
07:25 Avrem which is, replaces files I've deleted
07:25 Avrem from that from the central repository
07:30 omega I'm not sure, but can't you git checkout <deleted files>
to get them back?
http://colabti.de/irclogger/irclogger_log/git?date=2009-10-11#l545
(This adds a new twist to the "scm update" stuff, although svn/hg don't
seem to have "restore individual files" in their "update" command, so
this might be cvs-only. But it's so long since I used cvs, I don't even
know whether this is correct. But it somehow got me thinking about how
"update" is actually also "downgrade" in svn/hg, something git does via
"checkout" [which happens to make more sense to me]. And I think it
shows how "git pull" is taken to mean "update", even when ignoring the
special behaviour described here. It's not taken to mean "merge this",
but just "update to upstream").
So that's ten days of #git. I left out a bunch of duplications (most
were "pull == fetch", "pull == update" and "pull to update
non-checked-out branch").
Björn
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Wesley J. Landaker @ 2009-10-21 2:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Björn Steinbrink
In-Reply-To: <7v7huplkyj.fsf@alter.siamese.dyndns.org>
On Tuesday 20 October 2009 17:11:32 Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > Junio C Hamano wrote:
> >> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> >
> > ...
> > There would not be a configuration option.
> > ...
> >
> >> It's not even funny.
>
> Re-read what you were responding to and notice that I was commenting on
> Wesley's proposal that _is_ about a configuration variable.
Yes, I brought up the configuration variable, not Thomas.
My main goal was to try to suggest a transition plan that would be less
painful, but maybe it was actually worse. After reading Junio's response I
think I agree that going down that path might be the worst of both worlds,
but the basic model I was proposing (even if it's a bad idea in this case)
was largely basing on (my perceived impression of) how the recent changes to
push behavior were staged (i.e. with deprecation, new configuration
variables, etc).
I still think that, long term, making push and pull symmetric, EITHER by 1)
making push also update the working tree (in some sane way that I don't have
a proposal for) or 2) making pull be just about transfering objects, not
also merging (in some reasonable way that doesn't break useability, like
also adding "git update" or something at the same time) would be an overall
benefit.
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Sean Estabrooks @ 2009-10-21 1:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202044150.14365@iabervon.org>
On Tue, 20 Oct 2009 20:55:25 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Maybe, but it could also just be to create a temp local branch for
> > merging into additional branches afterward with "checkout other;
> > merge temp". This is especially helpful when pulling from an
> > annoyingly long URL instead of from a configured remote.
>
> Maybe it should be fine to do:
>
> $ git fetch long-url-here master:temp
> $ git merge temp
> $ git checkout other-branch-that-also-needs-it
> $ git merge temp
>
> But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
Well that's only one example of possibile uses for fetching directly to
a local branch, perhaps as a new base of further development. Is there
really a compelling reason to force someone to fetch into refs/remotes
and then do the extra step of checking it out locally?
> I think, actually, that creating or changing a local branch is really not
> what "fetch" (or the fetch part of pull) is about. I think that just leads
> to confusion about what's locally-controlled and what's a local memory of
> something remotely-controlled.
Well it's a handy shortcut for several situations. There must be a way
to protect less adroit Git users without removing functionality.
Sean
^ permalink raw reply
* Re: git gc and kernel.org
From: H. Peter Anvin @ 2009-10-21 1:00 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List, ftpadmin
In-Reply-To: <237967ef0910200208t290d7ba2l15c75081da5448de@mail.gmail.com>
On 10/20/2009 06:08 PM, Mikael Magnusson wrote:
>
> I don't know how you create repos on kernel.org, but by default both
> git init and git clone uses /usr/share/git-core/templates for the new
> repo, for example I put a symbolic ref h -> HEAD there to save some
> typing. You can enable whatever hooks you want there, but they would
> only take effect for new repos.
>
They only take effect for new repos, and any changes I do there get
messed up when git is updated.
-hpa
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 0:55 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Thomas Rast, git
In-Reply-To: <BLU0-SMTP889B2109047E949E039EFDAEBF0@phx.gbl>
On Tue, 20 Oct 2009, Sean Estabrooks wrote:
> On Tue, 20 Oct 2009 20:15:23 -0400 (EDT)
> Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> Hi Daniel,
>
> > Surely, "where you want the head stored locally" is somewhere that's
> > information about a remote repository, and therefore under "refs/remotes/"
> > (or "refs/tags/" or something) and therefore not possible to be checked
> > out (in the "HEAD is a symref to it" sense).
>
> Maybe, but it could also just be to create a temp local branch for
> merging into additional branches afterward with "checkout other;
> merge temp". This is especially helpful when pulling from an
> annoyingly long URL instead of from a configured remote.
Maybe it should be fine to do:
$ git fetch long-url-here master:temp
$ git merge temp
$ git checkout other-branch-that-also-needs-it
$ git merge temp
But "temp" is "refs/remotes/temp", not "refs/heads/temp"?
> > Actually, I think it would be good to prohibit fetching into a new or
> > existing local branch, whether or not it is checked out. We'd probably
> > need to provide a plumbing method of doing a fetch, though, for script
> > environments that aren't using the normal porcelain meanings of refs/
> > subdirectories. (Defining a bare repo with --mirror as not having local
> > branches, of course)
>
> I'm hoping you don't mean that all fetching to a new local branch should
> be prohibited and you're only talking about the current issue of full
> refspecs on and the pull command. Otherwise i'd say it seems
> unnecessarily restrictive.
I think, actually, that creating or changing a local branch is really not
what "fetch" (or the fetch part of pull) is about. I think that just leads
to confusion about what's locally-controlled and what's a local memory of
something remotely-controlled.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Sean Estabrooks @ 2009-10-21 0:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202001050.14365@iabervon.org>
On Tue, 20 Oct 2009 20:15:23 -0400 (EDT)
Daniel Barkalow <barkalow@iabervon.org> wrote:
Hi Daniel,
> Surely, "where you want the head stored locally" is somewhere that's
> information about a remote repository, and therefore under "refs/remotes/"
> (or "refs/tags/" or something) and therefore not possible to be checked
> out (in the "HEAD is a symref to it" sense).
Maybe, but it could also just be to create a temp local branch for
merging into additional branches afterward with "checkout other;
merge temp". This is especially helpful when pulling from an
annoyingly long URL instead of from a configured remote.
> I don't think it should be possible to fast-forward or create a local
> branch from a remote branch while simultaneously merging it into the
> currently-checked-out local branch.
What is the harm? Nobody is forced to use the facility and it does
have some marginal utility. I'd not fight for it, but i don't yet
understand the argument to prohibit it.
> Actually, I think it would be good to prohibit fetching into a new or
> existing local branch, whether or not it is checked out. We'd probably
> need to provide a plumbing method of doing a fetch, though, for script
> environments that aren't using the normal porcelain meanings of refs/
> subdirectories. (Defining a bare repo with --mirror as not having local
> branches, of course)
I'm hoping you don't mean that all fetching to a new local branch should
be prohibited and you're only talking about the current issue of full
refspecs on and the pull command. Otherwise i'd say it seems
unnecessarily restrictive.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] receive-pack: run "gc --auto" and optionally "update-server-info"
From: Nicolas Pitre @ 2009-10-21 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vljj5lofb.fsf_-_@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> Introduce two new configuration variables, receive.autogc (defaults to
> true) and receive.updateserverinfo (defaults to false). When these are
> set, receive-pack runs "gc --auto" and "update-server-info" respectively
> after it finishes receiving data from "git push" and updating refs.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Tue, 20 Oct 2009, Junio C Hamano wrote:
> >
> >> Nicolas Pitre <nico@fluxnic.net> writes:
> >>
> >> > Still... Hopefully this is going to become redundant information in the
> >> > future with the eventual deployment of smart protocol over HTTP. So I
> >> > think that as a config option being off by default this is a good
> >> > compromize. Site administrators can turn it on by default in
> >> > /etc/gitconfig.
> >>
> >> Ok, something like this?
> >
> > Looks fine to me, except...
>
> Everything you said sounded sensible. Thanks.
>
> Documentation/config.txt | 9 +++++++++
> builtin-receive-pack.c | 18 ++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index cd17814..ba6ed10 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1320,6 +1320,11 @@ rebase.stat::
> Whether to show a diffstat of what changed upstream since the last
> rebase. False by default.
>
> +receive.autogc::
> + By default, git-receive-pack will run "git-gc --auto" after
> + receiving data from git-push and updating refs. You can stop
> + it by setting this variable to false.
> +
> receive.fsckObjects::
> If it is set to true, git-receive-pack will check all received
> objects. It will abort in the case of a malformed object or a
> @@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::
> even if that push is forced. This configuration variable is
> set when initializing a shared repository.
>
> +receive.updateserverinfo::
> + If set to true, git-receive-pack will run git-update-server-info
> + after receiving data from git-push and updating refs.
> +
> remote.<name>.url::
> The URL of a remote repository. See linkgit:git-fetch[1] or
> linkgit:git-push[1].
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> index b771fe9..92173ac 100644
> --- a/builtin-receive-pack.c
> +++ b/builtin-receive-pack.c
> @@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;
> static int unpack_limit = 100;
> static int report_status;
> static int prefer_ofs_delta = 1;
> +static int auto_update_server_info;
> +static int auto_gc = 1;
> static const char *head_name;
> static char *capabilities_to_send;
>
> @@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
> return 0;
> }
>
> + if (strcmp(var, "receive.updateserverinfo") == 0) {
> + auto_update_server_info = git_config_bool(var, value);
> + return 0;
> + }
> +
> + if (strcmp(var, "receive.autogc") == 0) {
> + auto_gc = git_config_bool(var, value);
> + return 0;
> + }
> +
> return git_default_config(var, value, cb);
> }
>
> @@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
> report(unpack_status);
> run_receive_hook(post_receive_hook);
> run_update_post_hook(commands);
> + if (auto_gc) {
> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
> + }
> + if (auto_update_server_info)
> + update_server_info(0);
> }
> return 0;
> }
> --
> 1.6.5.1.107.gba912
>
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-21 0:15 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Thomas Rast, git
In-Reply-To: <BLU0-SMTP97AA2287062D9A104101C8AEC00@phx.gbl>
On Tue, 20 Oct 2009, Sean Estabrooks wrote:
> On Tue, 20 Oct 2009 20:23:06 +0200
> Thomas Rast <trast@student.ethz.ch> wrote:
>
> Hi Thomas,
>
> > git-pull has historically accepted full fetchspecs, meaning that you
> > could do
> >
> > git pull $repo A:B
> >
> > which would simultaneously fetch the remote branch A into the local
> > branch B and merge B into HEAD. This got especially confusing if B
> > was checked out. New users variously mistook pull for fetch or read
> > that command as "merge the remote A into my B", neither of which is
> > correct.
> >
> > Since the above usage should be very rare and can be done with
> > separate calls to fetch and merge, we just disallow full fetchspecs in
> > git-pull.
>
> It is however a handy shortcut to be able to specify the full refspec
> and specify where you want the head stored locally. It seems a shame to
> throw away that functionality because of one confusing case. Wouldn't
> it be better to test of the confusing case and instead error out if the
> local refname is already checked out?
Surely, "where you want the head stored locally" is somewhere that's
information about a remote repository, and therefore under "refs/remotes/"
(or "refs/tags/" or something) and therefore not possible to be checked
out (in the "HEAD is a symref to it" sense).
I don't think it should be possible to fast-forward or create a local
branch from a remote branch while simultaneously merging it into the
currently-checked-out local branch.
Actually, I think it would be good to prohibit fetching into a new or
existing local branch, whether or not it is checked out. We'd probably
need to provide a plumbing method of doing a fetch, though, for script
environments that aren't using the normal porcelain meanings of refs/
subdirectories. (Defining a bare repo with --mirror as not having local
branches, of course)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-20 23:56 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Björn Steinbrink
In-Reply-To: <200910201947.50423.trast@student.ethz.ch>
On Tue, 20 Oct 2009, Thomas Rast wrote:
> Hi all,
>
> While everyone is busy in two other UI threads, I figured I might as
> well toss up another (probably) controversial topic.
>
> Especially on IRC, we see many people who are some combination of
> misunderstanding, misusing or overusing git-pull. I figure this is
> the result of several factors, notably
>
> a) pull/push are not symmetric,
In a certain sense they are; they both update the branches local to one
repository with the data from the other repository. In this sense, fetch
is the oddity in that it doesn't update any repository's own branches, but
just the local information about other repositories' branches.
In another sense, push is unlike anything else in that it updates
something that's remote; in a third sense, pull is unique in that it can
generate a merge.
I suspect that what we've called "fetch" isn't what the people want when
they type "pull", either. And I suspect that the fundamental issue is that
the operation people are looking for is not the operation that they would
do best to use, regardless of naming. I think users are looking for
something that corresponds to "svn up", and they find "git pull"; this
isn't going to make them happy git users, but finding "git fetch" instead
is going to make them even more confused.
But I don't really know; are there IRC logs you can quote or reference
with people making the mistake you're trying to help them avoid?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Eugene Sajine
In-Reply-To: <7vbpk1lmvl.fsf@alter.siamese.dyndns.org>
> I am not sure what you mean by "static linking" anymore. Usually the word
> means that everything you tell the linker to link to the executable is
> linked, together with objects from libraries. The resulting executable is
> usable on its own and it does not change behaviour regardless of which
> version of dynamic libraries you depend on happen to be installed on the
> target system (because by definition a statically linked executable does
> not depend on dynamic libraries---that is the whole point of static
> linking).
>
There seems to be no misunderstanding in the static linking - i meant
the same thing. But let me put an example:
I have a program.exe
This program.exe is built basing on two statically linked libraries
lib1.lib and lib2.lib
I'm not developing any of those libraries, but only my own code of the
program.exe
Now, somebody changed 2 files in lib1.lib and 5 files in lib2.lib. But
i don't know that they are changed because it is different CVS module
or because I'm building against latest released libs or for whatever
reason...
When i rebuild my program the build supposed to pick up changes from
the libraries I'm using and relink, that will include 7 changed obj
files.
How can i say which exactly files are changed in my new version of
executable comparing to the previous version?
Currently they can take a look at the revision number of every
particular file included into the executable, which is put there by
CVS and compare it with the production. If the version is different,
then you know which files are changed and you can get diffs on them...
They also have file path and date and other stuff expanded...
Please note, my personal goal is *to prove that git can do that
better*, with less intrusion into the code sources, not other way
around.So, while keeping the info they want to have they might get
some benefits of git. Although, i understand that there might be no
cure for this state already, you can tell me that and I will close the
topic, but I just keep hoping;)
Thanks a lot,
Eugene
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Junio C Hamano @ 2009-10-20 23:28 UTC (permalink / raw)
To: Joe Perches; +Cc: kusmabite, git
In-Reply-To: <1256079633.2029.81.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> It seems that the regex for address validation
> isn't very good and perhaps there could/should
> be a stronger validation done for each address
> entered.
The existing ones are actually already harmful. It would trigger on a
valid addresses like this, wouldn't it?
To: "Hamano, Jun" <gitster@pobox.com>
It is worse than that.
The "# Verify the user input" block is in a wrong place in the codepath.
After @to goes through this bogus "verification" step, it then is given to
expand_aliases(), which may expand to real addresses. And then they pass
through sanitize_address() before getting used.
Three implications that come from this wrong code structure are:
(1) The stricter checks you added on top of the existing bogus
verification step may prevent @to to reach expand_aliases() step,
even if the tokens in @to may expand to correct addresses by this
expand_aliases() step if they were allowed to reach here;
(2) The result from expand_aliases() is never checked.
(3) The result from sanitize_address() is not checked either.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-20 23:16 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Wesley J. Landaker, git, Björn Steinbrink
In-Reply-To: <200910210053.29794.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Well, that reminds me of
>
> http://thread.gmane.org/gmane.comp.version-control.git/110251
>
> but was not really what I was aiming at.
Actually, if that patch weren't marked as [DRY HUMOR PATCH], and if it did
not have the detachInstead option, I would have at least queued it to
'pu', if not 'next'.
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Junio C Hamano @ 2009-10-20 23:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: Wesley J. Landaker, git, Björn Steinbrink
In-Reply-To: <200910210053.29794.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> ...
> There would not be a configuration option.
> ...
>> It's not even funny.
Re-read what you were responding to and notice that I was commenting on
Wesley's proposal that _is_ about a configuration variable.
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Joe Perches @ 2009-10-20 23:00 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0910201556h4757dbbdn853be4dd8aa920d0@mail.gmail.com>
On Wed, 2009-10-21 at 00:56 +0200, Erik Faye-Lund wrote:
> Didn't my version work for you? It worked for me.
Hi Erik.
It worked, but an unexplained die isn't great,
so I put it where the other validations are done.
It seems that the regex for address validation
isn't very good and perhaps there could/should
be a stronger validation done for each address
entered.
cheers, Joe
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Erik Faye-Lund @ 2009-10-20 22:56 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1256078917.2029.77.camel@Joe-Laptop.home>
On Wed, Oct 21, 2009 at 12:48 AM, Joe Perches <joe@perches.com> wrote:
>> Something along these lines? Of course, the error message is, uhm,
>> less than helpful :)
>
> Maybe this? Seems to work.
>
Didn't my version work for you? It worked for me.
I find it a bit cleaner to make it a part of the address-sanitizion,
since that needs to be performed for all addresses. I might miss
something vital, though. I don't really speak perl all that well ;)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 22:53 UTC (permalink / raw)
To: Junio C Hamano, Wesley J. Landaker; +Cc: git, Björn Steinbrink
In-Reply-To: <7vpr8hlow9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> > d) in mercurial, pull/push are symmetric, but fetch means pull+merge
Ugh. I can see how they arrived at hg-pull == git-fetch, but why on
earth was the logical next step hg-fetch == git-pull?!
</aside>
> > I would love to see this change, not because I get confused about pull/fetch
> > (it honestly only took a few days to get used to), but because having
> > push/pull be symmetric just is so much more conceptually pure / easier
> > explain to co-workers / separation between orthogonal operations /
> > satisfying to my inner perfectionist / etc.
>
> Is making "pull" a symmetric opposite of "push" the ultimate goal?
>
> Or is making (or rather "keeping") "pull" useful more important?
>
> It is not even an attitude that values philosophy over utility.
>
> Fundamentally, pull and push cannot be symmetric because nobody is sitting
> in front of the repository you are pushing into (that is what a "push" is;
> you push from outside the repository---otherwise you would be "pull"ing
> from inside it in the other direction), but you know you are sitting in
> the repository, ready to resolve potential conflicts, when you say "pull".
Well, I'd rather not argue the little semantic details, but I think
with the changes to disallow pushing into HEAD, push and fetch are as
symmetric as it gets. Both are exactly and only about transmitting
refs with their associated commits to the other side. Which one you
pick only depends on which side you sit on.
OTOH pull is about merging. And we can repeat the "pull = fetch +
merge" mantra to ourselves all we like, having pull as "the opposite
of push" is conceptually much easier to understand and thus far easier
to explain to new users.
> And you are doing this for what gain? The only thing I can think of is
> "People who deliberately set 'pull.merge = yes' can no longer blame us for
> pull not being the opposite of push." I do not consider it as a gain.
>
> I do not buy "People who set 'pull.merge = yes' now understand why pull
> touches their work tree, because they did it themselves" either.
[...]
> But I do not know what to say when people say "push cannot update the work
> tree, so let's make pull not to update the work tree by default---it will
> make it much less useful so we will fix that regression with yet another
> configuration option".
There would not be a configuration option.
Really, the whole goal would be to make pull the opposite of push. No
exceptions, and most certainly no little loopholes to escape into the
merging behaviour by default. The current 'git pull' behaviour would
either be obtained through a new command, or through an explicit
switch.
> I would be much more sympathetic if the suggested approach were to make
> "push" more symmetric to "pull", or at least attempt to allow it to be, by
> giving it an option to update the associated work tree when it can [*1*].
[...]
> *1* Obviously you cannot do this most of the time _if_ the work tree has
> an interactive user sitting in front of it, but in a repository that never
> allows a non-ff push, with a work tree that is never updated except by
> such a push, can reasonably be maintained to give an illusion of push
> being an opposite of pull by fast forwarding the work tree when the push
> updates HEAD.
Well, that reminds me of
http://thread.gmane.org/gmane.comp.version-control.git/110251
but was not really what I was aiming at.
> It's not even funny.
It was an RFC, not a joke ;-)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-send-email.perl defect: address missing trailing > accepted
From: Joe Perches @ 2009-10-20 22:48 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0910201529m338ef3d1o4fa1a31c3dcc2a20@mail.gmail.com>
On Wed, 2009-10-21 at 00:29 +0200, Erik Faye-Lund wrote:
> On Wed, Oct 21, 2009 at 12:12 AM, Joe Perches <joe@perches.com> wrote:
> > I typo cut/pasted an invalid email address,
> > neglecting to copy the trailing ">".
> > was: "Name <addr.org"
> > needed: "Name <addr.org>"
> > Anyone have suggestions on how to get
> > git-send-email.perl to notify and abort
> > sending on more invalid address styles?
>
> Something along these lines? Of course, the error message is, uhm,
> less than helpful :)
>
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -787,6 +787,10 @@ sub is_rfc2047_quoted {
> sub sanitize_address
> {
> my ($recipient) = @_;
> + if ($recipient =~ m/.*<[^>]*$/) {
> + die "EEK!"
> + }
> +
Maybe this? Seems to work.
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..52ddd9e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -374,15 +374,18 @@ my ($repoauthor, $repocommitter);
# Verify the user input
foreach my $entry (@to) {
- die "Comma in --to entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --to entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --to entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
foreach my $entry (@initial_cc) {
- die "Comma in --cc entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --cc entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --cc entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
foreach my $entry (@bcclist) {
- die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
+ die "Comma in --bcclist entry: '$entry'\n" unless $entry !~ m/,/;
+ die "Invalid --bcclist entry: '$entry'\n" unless $entry !~ m/.*<[^>]*$/;
}
sub parse_address_line {
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 22:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Bjrn Steinbrink
In-Reply-To: <20091021064243.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Thomas Rast <trast@student.ethz.ch>
> > 1. git-fetch gets options --merge/-m and --rebase that make it behave
> > like (current) git-pull, but requiring explicit arguments.
> > git-pull gets a new option --merge (-m) that only enforces presence
> > of arguments.
> >
> > 2. git-pull refuses to do any work unless given either --merge or
> > --rebase. Deprecation warnings for this start at the same time as
> > (1.).
> >
> > 3. git-pull becomes a synonym for git-fetch.
> >
> > 4. git-fetch gives deprecation warnings that point the user to
> > git-pull instead.
>
> Sorry, but I don't understand what's the improvement in the end
> result.
>
> I started reading your problem description and I thought you are
> fixing your item 'a) pull/push are not symmetric' by deprecating
> pull, to advertize fetch/push. Then asymmetry of push/pull stops
> being an issue.
>
> But it seems that eventually you will keep git-push and git-pull
> (because git-fetch gets deprecated); you have push/pull that are
> not symmetric.
By the time I get to that step, new-pull is current-fetch. So by that
time, push/pull *are* supposedly symmetric.
(Only deprecating pull never occurred to me, but then I really think
the strong association between them makes it worth keeping pull as the
opposite of push.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: ident hash usage question
From: Junio C Hamano @ 2009-10-20 22:30 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <76c5b8580910201514sc44f1cag222cf8a3710c875@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
>> If the project is already arranged to be compiled with decent automation,
>> I do not think you need any change to the workflow.
>>
>> You would have a version.cc file with
>>
>> static char program_version[] = "My Program " VERSION_STRING;
>>
>> in it, and teach the build procedure how to compile and link this file.
>> Something like:
>>
>> version.o: version.cc
>> $(CXX) -o $@ -DVERSION_STRING=\""$(git describe HEAD)"\" $?
>>
>
> Please, correct me if I'm mistaken and forgive me if I'm not correct
> in using C++ terms.
>
> Your solution proposes to have a version file which will carry the
> info about last state the program was built from.
> But as I understand in case of static linking the executable will get
> only obj files from a library, which are necessary and everything
> irrelevant will be thrown away by linker.
I am not sure what you mean by "static linking" anymore. Usually the word
means that everything you tell the linker to link to the executable is
linked, together with objects from libraries. The resulting executable is
usable on its own and it does not change behaviour regardless of which
version of dynamic libraries you depend on happen to be installed on the
target system (because by definition a statically linked executable does
not depend on dynamic libraries---that is the whole point of static
linking).
So as long as you make sure version.o is linked to the final executable,
you will be fine. One way to do so might be to have
printf("Program version: %s", program_version);
at the beginning of main() ;-)
If your product ships as one main executable _dynamically_ linked with two
dynamic libraries, and all three components are built from the source
material under your source control, obviously you would need to make sure
that the above version.o or some equivalent of what embeds output from
"git describe HEAD" are linked to the main executable and to the two
libraries, but the idea is the same.
^ 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