Re: [Simulavr-devel] about my recent commit to GIT repo

[Petr Hluzín]

Hi Onno

(This is my rant about Git/TortoiseGit. Others may want to skip reading it.)

On 21 December 2010 07:15, Onno Kortmann <address@hidden> wrote:
> Hi Petr,
>> It seems my GIT client recently committed [1] John McCullough's patch
>> [2] which adds support for CAN devices.
>> It was an accident. By looking in the repository I do not even know
>> the meaning of what I just did.
> It doesn't look that bad, indeed it seems that you did it right (except for a
> point which you can argue, see below). You didn't commit that patch, I did,
> and you should have received a message about this a bit ago.
>
> Basically, what happened is probably the following situation:
>
> 1. You updated your simulavr clone a bit ago, with a HEAD pointing to commit
> 122d192
>
> 2. You started working on this head (perfectly fine), committing your changes
> which are in commit e92725a
>
> 3. I committed John McCullough's patch as f56acc77 one the same HEAD of
> 122d192.
>
> 4. I pushed that change to the repository so tha the savannah's HEAD pointed
> to f56acc77.
>
> 5. This is now incompatible with the history of your repository and either a
> merge or a rebase of your changes needed to happen. Incompatible means that
> you were not able to push these changes back,

At this point I expect a diagnostic from the tool say something like
"there has been 1 commit in remote repository since last
Merge/Rebase/Sync/Whatewer. Do click XY to get the commit or use ZZZ
for more advanced things".

> as that would have lost my patch
> as a push can only be a forward to another commit, with an intact history
> leading to it, but basically your commit was not matching the existing history
> anymore.

That would not have lost your patch, since my changes affected
different files or different parts of the same file. A non-conflicting
merge.

> Now, mostly, people do a rebase of their own stuff onto the current upstream
> HEAD instead of a merge for a set of upstream changes, if possible, to avoid
> creating a more complex devel history. But a merge is perfectly fine. That's
> the only point that can be argued. You witnessed the distributed version
> control system in action :-)

No, I witnessed lame implementation of a distributed version control
system. The tool (Git or TortoiseGit, I do not know how they split
their responsibilities) could have said what is happening, why, what
is the recommended action.

If it cannot automatically resolve non-conflicting merge than it is as
powerful MS SourceSafe. I know that Git can be forced to do that, but
this operation should be obvious. After all I got opened "Git
Synchronization" window, what is the point of the window if not
synchronizing (with obvious effects)? I am ok if it offers some
advanced ways how to synchronize that if the advanced ways look
advanced. The window is supposed list remote changes not contained in
local repository and local changes not contained in remote, simple
thing.

(And no, local repository is not "master", it is a necessary evil for
small projects like ours. For huge projects like Linux the Linus' repo
is the master, so no match there either.)

>>
>> Do you recommend some user-friendly Git client for Windows?
> I only know of TortoiseGIT and only used it a time ago as it was still
> considered to be in heavy development, but the basic stuff should work? What 
> is
> the exact complaint?

In TortoiseGit in Git Synchronization window when I press Push:

# git.exe push -v  "origin" master:master
# Pushing to git://git.savannah.nongnu.org/simulavr.git
# fatal: The remote end hung up unexpectedly

In Git Synchronization window if I switch item "Remote Url" to the
item "originwithauth" with associated URL of
address@hidden:/srv/git/simulavr.git:

# Don't know what will push because unknown "originwithauth/master"

>From commandline:
# G:\backups\projects\simulavr-git2>"C:\Program Files\Git\bin\git.exe" push
# fatal: The remote end hung up unexpectedly

I know these messages have a quite reasonable explanation. It is the
tools job to provide it.

-- 
Petr Hluzin