Git + launchpad [LWN.net]

Git + launchpad

Posted May 6, 2015 7:56 UTC (Wed) by NAR (subscriber, #1313)
In reply to: Git + launchpad by smurf
Parent article: Git code hosting beta (launchpadblog)

You can undo commits, but can't undo interactive rebases or pushes. I have met the sharp pointy end of these commands. Of course it was my fault (in fact, I expected to err, so I saved the diff before the rebase), but nevertheless the tool has sharp pointy ends. The scalpel of a surgeon has also sharp pointy end, otherwise the surgeon couldn't do it's job...

to post comments

Git + launchpad

Posted May 6, 2015 8:17 UTC (Wed) by cebewee (guest, #94775) [Link] (5 responses)

Of course you can undo interactive rebases in Git. The reflog (git log -g) is your friend.

Git + launchpad

Posted May 6, 2015 9:36 UTC (Wed) by tpo (subscriber, #25713) [Link] (4 responses)

git log -g? First time I've heard of that.

<rant>
And *of course* there's also git's own virtual machine and C like language that can be used to fix further stuff, because you can't really expect to use such advanced machinery as a "commit" without knowing the third order relations of quantum git algebra.
</rant>

Git + launchpad

Posted May 6, 2015 12:31 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

What? Commit doesn't require that knowledge. It *helps* to know what git is doing behind the scenes, but is by no means necessary.

Git's flexibility let's me write a tool that uses one clone to spawn X empty directories in which to do manipulations on the repository (such as running hooks, merging, etc.) without actually checking a workdir out (an bottleneck when you do it thousands of times a day on large repositories). Now, most people don't need to know about things like update-index, ls-files, or read-tree, but I really don't know how'd I'd even approach the problem with another VCS while staying in the requirements (though I admit ignorance, at least to the same depth I know of git, of other tools) since I don't think they give me the same tools. It also let's me atomically write references out to avoid race conditions when these parallel workdirs write back notes to keep the work they do around from being garbage collected.

Git + launchpad

Posted May 6, 2015 15:36 UTC (Wed) by pboddie (guest, #50784) [Link] (1 responses)

By "without actually checking a workdir out", do you mean like Mercurial clones which have been updated to the null revision? (You get the .hg directory and nothing else.)

I imagine bzr permits the same, although my experience with bzr has been mostly to dip into some repository someone has asked me to look at, and to run some fairly intuitively-named commands, which did what I expected. Quite a contrast to Git, in fact.

(It seems to be the case that criticism of Git's usability is frequently met by retorts that it's an object filesystem and sink-cleaner all in one, and that the frustrated user should feel the power. The manpages, despite probably having had a few iterations, reinforce this impression: git-checkout is my current "favourite".)

Git + launchpad

Posted May 6, 2015 21:11 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

You make a file path and an empty directory, set GIT_INDEX_FILE and GIT_WORK_TREE in the environment pointing to those and set GIT_DIR pointing to the bare repository with all the objects. We then prep the index with the right revision (git read-tree), tell the index that the working tree is OK without hitting disk (git update-index), and then checkout the .gitmodules file (if it exists) (git checkout-index followed by git update-index to update it that there's a real file on disk now) so that submodules work properly. This can be done concurrently with a single clone of a repository and each chain of commands thinking they are working on a real thing (you need the directory so that conflict files have a place to be dropped).

So basically, can I work with a single clone from multiple directories at once where all of them think they are in their own little sandbox and don't interfere with each other (even to the point of avoiding race conditions when asking for available names in refs/)?

I agree that the git docs are not as end-user-oriented as they could be. I'm also not *too* concerned with intuitiveness (cf. my use of Vim, XMonad, tmux, uzbl, etc.), but rather that things *make sense*. As an example, the "standard" cut/copy/paste shortcuts are convenient, but are not composable like Vim's versions of them. That's what I like about git; it gives me a toolbox with some pre-made tools composed of the bare bits rather than a completed sawsall or something which, while nice, can't quite be made into a hammer when I need one without some sanity checks.

Git + launchpad

Posted May 6, 2015 20:45 UTC (Wed) by nix (subscriber, #2304) [Link]

Git's own what? It doesn't have a virtual machine, nor a C like language. Its revision specifiers look more like the shell than anything.

You may be thinking of Mercurial here (which *also* doesn't have a virtual machine of any sort, but which has ways to specify revisions that look more like a conventional programming language).

Git + launchpad

Posted May 6, 2015 8:17 UTC (Wed) by alexl (guest, #19068) [Link] (1 responses)

You can undo an interactive rebase, or any changes to a (local) git repository that has been commited (but not if you accidentally lose outstanding changes). Every single commit is kept in the repo as long as you don't trigger a GC, so the head before the interactive rebase is still there, and can be found via "git reflog".

Git + launchpad

Posted May 6, 2015 12:35 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

FTR, commits stay around if they have a name (branch, tag, other arbitrary ref, reflog entry, etc.), or a path from a name, or are younger than 30 days (by default).

Git + launchpad

Posted May 6, 2015 11:50 UTC (Wed) by agateau (subscriber, #57569) [Link]

While in the middle of an interactive rebase, you can undo it with `git rebase --abort`.

Furthermore, when I know I embark into some heavy rebase, I start by creating a branch for the rebase with `git checkout -b rebased`. I then do the rebase in this branch. This is quite handy because when I am done I can easy compare the two branches with `git diff name-of-original-branch`.

Git + launchpad

Posted May 6, 2015 18:05 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

AIUI, if you make a note of what the current head is, you can ALWAYS get back to it unless BOTH you abandon that branch AND you do a garbage collect.

Otherwise, it's all part of your history, and knowing the commit means you can reset that to be you current working head. So if you reset the head back somewhere in the history (or abandon that head) a GC will detect the hanging end and garbage-collect backwards, but as long as there is an active commit after the one you want, it can't be GC'd, and it can be retrieved.

Oh - and aiui you can also back up your working directory - "git stash" if I've got it right. I don't use it, I don't understand it, but that's what it's for.

Cheers,
Wol

Git + launchpad

Posted May 6, 2015 20:47 UTC (Wed) by nix (subscriber, #2304) [Link]

AIUI, if you make a note of what the current head is, you can ALWAYS get back to it unless BOTH you abandon that branch AND you do a garbage collect.

The garbage collection also must have happened at least as long after the rebase as specified by the gc.pruneexpire config option (if unset, two weeks).

You need to really work to lose committed data in git.

Git + launchpad

Posted May 6, 2015 20:23 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

git reflog?

Git + launchpad

Posted May 7, 2015 15:37 UTC (Thu) by smurf (subscriber, #17840) [Link]

Sure you can undo a push. "git push -f destination OLD_COMMIT_HASH:branch". Or, if you want to delete a remote branch, leave OLD_COMMIT_HASH empty.

Sure you can undo a rebase. "git reset --hard OLD_COMMIT_HASH".

You get the old commit hash from the reflog, or from a gitk window you conveniently left open, or whatever.

I never had to "save a diff", by the way. What would that accomplish?