Mostrando entradas con la etiqueta git. Mostrar todas las entradas
Mostrando entradas con la etiqueta git. Mostrar todas las entradas

viernes, 9 de julio de 2021

Show other revisions of a file with magit

Magit proper offers magit-find-file and magit-find-file-other-window, that ask you for both revision and file. At least they autocomplete with sane defaults. 

The thing is my usecase is 99% "current-file in previous-branch in a split window".

As easy as

(defun rgc/magit-find-file-dwim ()
  (interactive)
  (magit-find-file-other-window (magit-get-previous-branch) (buffer-file-name)))

You get a nice command to open the current file from the previous branch you visited in your repo. 

Often, next immediate  command is m-x ediff-buffers RET. (yeah, maybe adding that would make it even more dwim).

If you'd want to do it in the command line, something like 

    git show branch:file

Would do, but you'd have to type both branch and filename.

 

miércoles, 31 de marzo de 2021

Interesting new-old takes on git

It seems there are a few things going on lately on the git subspace.

For one, ppl are talking about the mail flow vs Pull Request flow. It's interesting how people go back and forth on those: https://blog.brixit.nl/git-email-flow-versus-github-flow/

 Here's an interesting take at git flows again. Git plan focuses on writing the commit message before doing the commits. Maybe it's something to fix the issue/pr dicothomy?: https://github.com/synek/git-plan

And an experience report of using squash+merge for couple of years. That's interesting because it's what we are using at work, and even though I'm skeptical about its advantages, it's nice to see how people perceive the effects of squash+merge: https://blog.dnsimple.com/2019/01/two-years-of-squash-merge/

And a bonus of HN thread with some git helpers using fzf: https://news.ycombinator.com/item?id=26634419


sábado, 5 de septiembre de 2020

Radicle: Secure peer-to-peer code collaboration without intermediaries

That's a pretty neat project I've stumbled upon. Radicle.

It tries to do a really distributed code management solution by building upon a few concepts I consider super interesting and rock solid. 

I'm gonna be throwing a few keywords that lighted up when reading about it (they might or might not appear as direct references in radicle's articles).: 

  • Git 
  • Merkle trees 
  • P2P 
  • gossip protocols 
  • IPFS 
  • Scuttlebut 
  • pijul 
  • nix 
  • Rust 

 

That's a lot of cool stuff! I wish I had a bit more time, but lately I'm so much into Red language that I devote 80% of my free time to it. Still learning the basics of its toolchain, but it seems very impressive to me so far.

 

And here is something totally unrelated, but I enjoyed it so much I have to post it somewhere. A reverse engineering video of Contra (NES videogame from the 80's), with explanation of the konami code.

domingo, 26 de abril de 2020

What's in a git merge conflict?

There's something that was bothering me lately about git conflicts:

How come git knows which side is which, and when there is a conflict or where there isn't?

I have the notion of the common ancestor to base the versions off of, but when people do heavy cherry-picking (which is mostly a single branch operation).... how come git reconciles the contents?

Well... as usual, things in git are..... simpler?

https://stackoverflow.com/questions/4920885/what-constitutes-a-merge-conflict-in-git





lunes, 25 de noviembre de 2019

Git from the ground up

There's this recent amazing video about org-mode, that happens to use git internals as the topic of the org mode document. And I just remembered the Aha moments I got when I started grasping git internals.  Here's what made stuff click to me.

- https://www.youtube.com/watch?v=ig5E8CcdM9g
- https://www.youtube.com/watch?v=MYP56QJpDr4
- https://www.youtube.com/watch?v=1ffBJ4sVUb4
- http://ftp.newartisans.com/pub/git.from.bottom.up.pdf


Also, https://initialcommit.io/#baby-git seems like a very nice deep dive into git internals from its core ideas.  I haven't had the time to dig into those articles yet, but worth mentioning them.
And last but not least: A very plain but smart way to investigate git: https://www.reddit.com/r/git/comments/eel2cf/how_does_gitstash_work_under_the_hood/fbubxvz/ . Kinda emacs' "c-h k", but for git.

martes, 4 de junio de 2019

TIU: git merge -Xpatience -Xignore-all-space

For better or worse, I'm becoming an expert on git merges.

Today I got to use (TodayIUsed) the special flags: "git merge -Xpatience -Xignore-all-space  mybranch".  And it makes a difference!


Trying imerge again was a bit of a failure due to one of the two branches behaving very bad (lots of churn in the same lines over and over, so it felt like a rebase).

jueves, 7 de febrero de 2019

TIL: paste -sd+

Following https://hacker-tools.github.io/ lectures, I found a neat trick I didn't know in the data wrangling chapter:

seq 100 | paste -sd+ | bc -l     # 5050


That's pretty nice.  I already had this usecase solved by an "addup" perl script that I stole years ago from Mark Jason Dominus' utils repo.

As a bonus, it reminds me the very similar trick to generate a regex that matches either of many words. That's part of my git pre-commit hook


Not exactly the same, but it also belongs to "Higher Order Shell"

miércoles, 25 de julio de 2018

meta git-tip-of-the-day

curl https://raw.githubusercontent.com/git-tips/tips/master/tips.json |
     jq 'map([.title, .tip] | join(" --> ")) | join("\n")' -j | 
     shuf -n1

jueves, 11 de mayo de 2017

Git 2.13 has been released

As you can see in github blog, there's a new git version (2.13).

There are some internal and some external changes, but the one that stroke me as most useful for me is conditional configurations.

Conditional includes, means that you can preset in your ~/.gitconfig some conditions, like

[includeIf "gitdir:~/work/"]
  path = .gitconfig-work
[includeIf "gitdir:~/play/"]
  path = .gitconfig-play
 
Now you can put whatever options you want into those files:

$ cat ~/.gitconfig-work
[user]
name = Serious Q. Programmer
email = serious.programmer@business.example.com

$ cat ~/.gitconfig-play
[user]
name = Random J. Hacker
email = rmsfan1979@example.com  

After that, you'll be able to commit away in any project in your computer, and git will do The Proper Thing.  This is just awesome, that all the hackery I had to simulate this can now go away.  I'm going to add this to my configs NOW. :)


As this is a git post, I'll take the opportunity to mention this blogpost about filter branch. Also, this one about packfiles. Both are advanced topics, but you know..... it's fun :)

martes, 14 de marzo de 2017

git reflog with dates

reflog is this superhero that only appears when it has to save your ass.

A neat thing about it is that it logs everything you do in a given machine. It works locally, none of the reflog is pushed anywhere, and if you 'git clone', your reflog is empty. But...

For us, that are work are doing very far from BlueGreenDeployments, by doing git pull in a server and reloading (in Common Lisp planet you do hot reloads like a boss), this gives a track of when did pulls happen, and so you can find re-imagine the history of deploys, pulls, deploys, fixes.

It's a suboptimal solution, but given it's for free "don't look a gift horse in the mouth".

As usual in the class of git commands that list info, there are lots of formats and customizations.  For me, a simple "git reflog --pretty=oneline --date=short" does the job. 

jueves, 19 de enero de 2017

git contribution spans (emacs case study)

 Let's play a little, just for the fun of it, and to gather some metainformation about a codebase.

I sometimes would like to find out the commit spans of the different authors. I may not care about the number of commits, but only first and last. This info may be useful to know if a repo has most long time commiters or the majority of contributors are one-off, or one-feature-and-forget.

First we'll sharpen a bit our unix chainsaw:

Here's a little helper that has proven to be very useful. It's similar to uniq, but you don't need to sort first, and also it accepts a parameter meaning the column you want to be unique. (Unique by Column)

function uc () {

    awk -F" " "!_[\$$1]++"

}


And then, you only have to look at man git-log to find out you can reverse the order of the logs, so you can track the first and the last appearence of each commiter.


git log --format='%aE %ai'  | uc 1 | sort  >/tmp/last

git log --reverse --format='%aE %ai -> '  | uc 1 | sort >/tmp/first

paste /tmp/first /tmp/last > /tmp/spans.txt


Here is the output file. it has some spurious parsing errors, but I think it still shows how powerful insights we can get with just a bit of bash, man and pipelines.

Just by chance, the day after I tried this, I discovered git-quick-stats, which is a utility tool to get simple stats out of a git repo. It's great that I could add the same functionality there too via a Pull Request :).

Big thanks to every one of the commiters in emacs, being long or short span and amount of code contributed. Thanks to y'all 

lunes, 25 de julio de 2016

git pre-commit blacklist

Here's a simple solution if you want git to not allow you to commit debug messages or blacklisted words.

The nice thing about the snippet is that it only counts added lines, not removed, so you can clean code with this pre-commit active, but never make it worse.


FORBIDDEN='declaim\|break'
git diff --cached | grep '^+' |  grep -n $FORBIDDEN && \
 echo "COMMIT REJECTED Found '$FORBIDDEN' references. Please remove them before commiting" &&\
 exit 1

martes, 21 de junio de 2016

TIL: git ignore files locally

Adding this simple line to your .gitconfig you have an easy and semiautomated way to ignore files on your working tree, without messing the repo's .gitignore.

There's a file called .git/info/exclude that is basically another .gitignore file, but it never gets commited. So with the following line in your configs you can:

git exclude '*.csv'

And now the line itself:

exclude = !sh -c 'echo "$1" >> .git/info/exclude' -

miércoles, 21 de octubre de 2015

Command line bookmarks

I saw a Gary Bernhardt's talk where he explains a few console tricks. Most of the tricks themselves I already knew, but the biggest outcome of seeing the talk is the motivation for scripting everything and using small functions to use bash/zsh the fastest possible way.

I'm a big fan of zsh, and I have a fairly big .zshrc (101 aliases, for example).

At work, we use a quite strict and orthogonal way to tag all project issues, so that one can find out easily which issues are waiting for merge, which are halted, or which are being worked on.  As we use github, the usual way is log into github (or waffle) and search .

But when it starts getting repetitive, I usually think how to do it faster. one option was bookmarks in conkeror, but it didn't quite work.

Now, I'm using this in my .zshrc :

BROWSER=/home/rgrau/bin/conkeror
PROJECT=projectname

function ghnext {$BROWSER "https://github.com/3scale/$PROJECT/issues?q=is%3Aopen+label%3AT-core+label%3AB-Next"}
function ghmerge {$BROWSER "https://github.com/3scale/$PROJECT/labels/needs%3A%20merge"}
function ghmy-issues {$BROWSER "https://github.com/3scale/$PROJECT/issues?utf8=%E2%9C%93&q=is:open+assignee:kidd"}
function gh3scale {$BROWSER "https://github.com/3scale/$PROJECT"}
function ghissues {$BROWSER "https://github.com/3scale/$PROJECT/issues"}
function ghcurr {$BROWSER "https://github.com/3scale/$PROJECT/issues?q=is%3Aopen+label%3AB-current+label%3AT-core"}
And here is gary's talk:

jueves, 13 de noviembre de 2014

Checking what's new with git

Short post today, but kinda useful IMHO.

From time to time I have to show my bosses what our team has done in the last period. We use 2 weeks as our sprint lenght (although we're not following scrum strictly).

Anyway, I was looking for a way to summarize the activities of the team, and instead of trying to remember, or having to write annotations for the next report, I just crafted this nifty little git log command which allows me to know which branches have been merged to master in the last 2 weeks.

So now, 5 minutes before the meeting I just run it and see what I have to debrief to my bosses (or other teams in the company).

git log --since=2.weeks.ago --merges --branches=master --first-parent --graph --pretty=oneline | sed -e 's/.* from/*/'  

Try it in your repos, and see how it works for you. For me it pretty much nails it.

viernes, 28 de marzo de 2014

git reset. again

This is shamelessly copied from the web archive.

Assume you start from a "everything is committed and golden" state. Let's pretend you came to this starting point via a git checkout: and then you edit a bunch of stuff, compile/test, and then git add and git commit:
$ git checkout mywork
...edit edit edit...
$ git add ...
$ git commit
If at this point you do a git reset, here's how the type of reset ("soft", "hard", or the default, which is "mixed") affects things:
$ git checkout mywork
            # --hard resets to this point
...edit edit edit...
            # --mixed (default) resets to this point
$ git add ...
            # --soft resets to this point
$ git commit
Also note, as gitster says, that git commit --amend makes the git reset --soft mostly redundant.

lunes, 21 de octubre de 2013

TIL: 2013-10-21

Wanna know in which branches can you find a given commit?
git branch --contains [treeish]

miércoles, 18 de septiembre de 2013

Pretend you never pushed that file in git

Years ago, when I was starting to use git, I commited (and pushed) a file I didn't want. It was a huge TAGS file, which made the repo unusable.

 At that time I found a way to remove it, but today I stumbled upon a github page which explains it way better.

Enjoy