Re: git: how to figure out with a script what the last commit on remote repo is without fetching it
Joel Rees <joel.rees@gmail.com> writes:
> 2014/09/19 5:27 "lee" <lee@yun.yagibdah.de>:
>>
>> Joel Rees <joel.rees@gmail.com> writes:
>>
>> > On Sun, Sep 14, 2014 at 10:43 PM, lee <lee@yun.yagibdah.de> wrote:
>> >> Joel Rees <joel.rees@gmail.com> writes:
>> >
>> > Hmm. So. When you do a
>> >
>> > git status
>> >
>> > on the command line, with the current working directory at the
>> > appropriate place in the repostory, you have taken the trouble to
>> > specify your repository as something like
>> >
>> > http://git.code.sf.net/p/asm68c/code
>> >
>> > instead of
>> >
>> > git://git.code.sf.net/p/asm68c/code
>> >
>> > ?
>>
>> In one case, I cloned it; in another, I don't know anymore what exactly
>> I did.
>
> This is something you really need to understand. I strongly encourage you
> to dig into it.
Well, I didn't make some sort of recording of what I did back then, so
there's no way to find out.
>> > I think git is the usual/default protocol when you clone a repository.
>>
>> I don't know --- look at an arbitrary repo on github, and you'll find
>> yourself presented with an http URL to clone it. Look at the emacs
>> git-repo, and you're presented a git URL to clone it.
>
> You know, I don't use github. I just checked what they offer, and it looks
> like the web interface is optimized for web based use, which makes sense.
> But web-based is by no means the only interface.
There doesn't appear to be any interface which helps you with getting
informed about commits automatically. A web interface is rather
unsuited for this.
>> In any of the cases, I'm *not* being informed about new commits. I need
>> to look for them one way or another, and I'd rather get an email that
>> informs me automatically.
>
> If git status is not telling you about pushes to the repositories you are
> accessing, you've got your HEAD set to something else, maybe a branch point
> or a historical point.
'git status' does tell me. That's what the script is currently using.
> I had the idea that maybe you were just interested in the activity, not in
> the resulting code, which I see is not the case.
Yes, when there are new commits, I may want to pull them. That's why I
want to be informed automatically when there are any.
>> Probably not --- we'd have to ask the developers of git why such an
>> important feature is missing.
>
> There are some that do. The hooks are available to the repository
> adminstrators in git.
Which doesn't really help the users ...
>> > And you should also consider that, with git, the assumption is that
>> > everyone is mostly working on their own clone of the repository,
>> > sometimes doing diffs and so-forth with other developers'
>> > repositories, and only occasionally going to a central repository.
>>
>> How would that work, or why would they make a copy at some point in
>> time, work totally isolated on that for a year or for many years and
>> only then look at a central repo eventually? That doesn't make any
>> sense to me.
>
> Years or days, or minutes, which you consider central is your choice.
> Shifting your HEAD to a different repository does require a bit of work in
> merging code, but the repository doesn't really care.
When there is a number of ppl working on something, you may have to
update your clone of the repo somewhat frequently rather than sticking
to what you already have, unless you prefer to work on outdated stuff.
When "everyone is mostly working on their own clone", as you say,
they'll all be working on outdated stuff.
>> Git is supposed to be a tool for collaboration, isn't it? People
>> working together on something would probably have a hard time to
>> collaborate through isolating themselves by not keeping track of a
>> central repo or by not keeping track of everyone elses repo.
>
> When they say git is for de-centralized collaboration, they mean it.
>
> Well, you do have to make choices about which repository you set as HEAD at
> any particular point in time.
When "everyone is mostly working on their own clone", they do not
collaborate, neither non-centralised, nor otherwise.
>> Once someone pushes to the central repo (or their own),
>
> There is no central other than the one you specify. And you don't push to
> your own (unless you decided to keep a local "central" of your own,
> separate from your working copy).
Then how do I load a file of my repo on github into emacs to edit it?
Do they offer some sort of remote access? And what would I do when I
modified the file? Do they offer some sort of remote control for git so
that I can commit my changes?
> You commit into your working repository and then push your commits to
> wherever you are pushing them to when you think it's time to push them
> outside your working copy.
The repo on github is a copy of what I have. It's my repo, so of course
I push to it.
Other than that, yes, the way git thinks is extremely stupid: It thinks
that repos are always remote and that such remote repos dictate what's
going on in your clone. Actually, it's the other way round.
>> everyone else
>> may want to have the latest version
>
> Actually, not necessarily. Generally, you decide when to merge code on
> criteria of your own. You often don't want the latest,
yes
> and you may in fact want to keep your head pointed a bit behind the
> latest as a matter of practice.
I wouldn't know how to do that.
>> and thus needs to pull --- or they
>> decide to wait when looking at the change log. How does everyone get
>> informed about new commits (when a hook that sends out an email isn't
>> used)?
>
> git status
> git diff
>
> and setting the appropriate head between issuing either.
'git diff' only tells you what changed in your clone, not what the
changes between the remote or upstream repo and your clone are. That's
stupid, too, because git thinks that everything is remote and doesn't
allow you to do anything with the remote repo other than fetch and push,
which doesn't make any sense.
>> Everyone would have to track the centralised repo, or various repos, by
>> manually using a web browser or some other manual means to see what's
>> going on. It's stupid when you have to do that.
>
> Well, setting aside the web browser comment, perhaps what you are missing
> is that git makes such manual specification of what you are comparing your
> code to relatively easy, maybe so easy that you accidentally set your head
> back off the latest without knowing that's what you did. And it will remain
> set there until you set it again, which is the reason diffs, status , and
> even pulls don't see any changes.
I'm not aware of setting anything to tell git what to compare something
to. Diffs see only local changes, pulls work fine, and status tells me
when the remote repo "diverges". That makes status the only thing that
actually tells me something about the remote repo in comparison to my
clone.
--
Knowledge is volatile and fluid. Software is power.
Reply to: