DEV Community: Afif Sohaili

Bring your lost git commits back from the grave.

Afif Sohaili — Fri, 02 Oct 2020 10:05:15 +0000

The background

I was trying to rebase my branch against the latest ~~master~~ main branch one day, which had some new changes from my colleague. Unfortunately, those changes actually had conflicts with the changes on my branch. Obviously, git then asked me to resolve the conflicts when I tried to do a rebase, and so I did. But after I was done, I realized that the changes on my branch no longer worked, and upon further digging, I seemed to have not resolved the conflicts correctly, hence introducing a bug in my branch.

So I tried git diff-ing against the latest main branch again to see what I did wrong. But because the conflicts were quite complex and with all the lines of additions and deletions jumbled in-between each other, detecting the problem couldn't just be done in a glance. I had to resort to a more extreme approach, starting over on my rebase.

That means I had to reset my current branch to the state before I did the rebase, so I had to get that commit hash from before. I cannot get that from my branch now, since if I run git log on my branch, it will show the commit hashes after the rebase. But not to worry, right? Because I could obtain the old commit hash by referring to my branch on remote (in this case BitBucket). And here was when I realized that I did another crucial mistake: I did not push my branch to remote, at all. All my commits were just in my local repository.

So, now what?

`git reflog` to the rescue

And that was when I stumbled upon git reflog, a handy, little-less-popular feature of git that I love. According to the documentation, git-reflog:



record when the tips of branches and other references were updated in the local repository.

That means, whenever you do any operation in your local git repository, it gets logged into reflog. That's right; when you create a new commit, that gets logged. When you amend a commit, that gets logged. When you checkout to a different branch, that gets logged. When you cherry-pick a commit, that gets logged. When you rebase, each steps git takes to rebase your branch gets logged. You can try git reflog now on any of your git repos and you will see all the operations you did in your local repo.

Bringing back the lost commit from reflog the grave

So, with this new knowledge equipped, I could solve the problem I described earlier. I ran git reflog, traced the last commit I made before the rebase and copied its commit hash, and simply ran git reset --hard <the old commit hash>. And voilà, I was back at square 1 (sort of, see Footnote 1). I then re-ran git rebase master to repeat the merge conflict resolution process, and resolved it properly this time.

Conclusion

And that's how you bring back commits from the grave. Yes, you might not need this everyday. But when you do need it, you'd be glad it exists. I know I did.

Footnote 1

git will actually record your merge conflict resolution the first time you do it, so even if you rerun git rebase master, it will apply those recorded resolutions and you might see your buggy merge conflict resolution again. To resolve this, run:



# rerere stands for reuse recorded resolution
git rerere forget path/to/file/with/buggy/resolution

or if there's a ton of files, just run rm -rf .git/rr-cache.

I actually wish I could disable git rerere. I don't find it useful tbh.

Footnote 2

You can run git reflog expire to delete these dangling commits. By default, it'll keep the commits created within the last 90 days. I believe they'll never get deleted ever if you don't run this command or git gc command, but I could be wrong. In any case, I don't think you'll want to dig up dangling commits from beyond 90 days ago. There's gonna be so much noise.

How Does Your Team Do Tech Debt Analysis?

Afif Sohaili — Tue, 04 Feb 2020 05:58:32 +0000

Right now, my team analyzes the bugs we've fixed within the last month and discuss about them, like what to do to prevent them in the future. We also discuss certain metrics on our products' debts, like test coverage, code complexity, risks, etc.

I'm gathering ideas on how everyone else is doing tech debt analysis and wondering if we could steal some ideas for my own team so that we could make these sessions more effective.

Here are a couple of questions I'd like to inquire:

What's the general process for identifying/analysing tech debts in your team?
What tools do you use to facilitate the discussion?

Dealing with Promises In an Array with async/await

Afif Sohaili — Fri, 14 Jun 2019 07:47:23 +0000

Promises and async/await is a welcomed addition to the newer versions of JavaScript. If you are not using it yet and are trapped in the callback hell, you might want to check it out and start using it already. Believe me, it's awesome! The MDN docs would be a good place to start, and CSS-Tricks has a good article on it as well.

But it can be a little bit tricky when using async/await to deal with a collection of promises. Thankfully, here is my cheatsheet for dealing with them, created based on my experience.

p.s. No external libraries! 😉

Now, let's get started! Imagine we have the following asynchronous functions:

const resolveInTwoSeconds = () => {
  return new Promise((resolve) => {
    setTimeout(() => resolve(2), 2000);
  })
};

const resolveInThreeSeconds = () => {
  return new Promise((resolve) => {
    setTimeout(() => resolve(3), 3000);
  })
};

const resolveInFiveSeconds = () => {
  return new Promise((resolve) => {
    setTimeout(() => resolve(5), 5000);
  })
};

1. Wait for all promises to complete with Promise.all

Promise.all accepts an array of promises and returns a new promise that resolves only when all of the promises in the array have been resolved. The promise resolves to an array of all the values that the each of the promise returns.

(async function() {
  const asyncFunctions = [
    resolveInTwoSeconds(),
    resolveInThreeSeconds(),
    resolveInFiveSeconds()
  ];
  const results = await Promise.all(asyncFunctions);
  // outputs `[2, 3, 5]` after five seconds
  console.log(results);
})();

2. Wait for at least one promise to complete with Promise.race

Promise.race accepts an array of promises and returns a new promise that resolves immediately when one of the promises in the array have been resolved, with the value from that promise.

(async function() {
  const asyncFunctions = [
    resolveInTwoSeconds(),
    resolveInThreeSeconds(),
    resolveInFiveSeconds()
  ];
  const result = await Promise.race(asyncFunctions);
  // outputs `2` after two seconds
  console.log(result);
})();

3. Wait for all promises to complete one-by-one

The easiest, most straightforward way to achieve this is by using plain old for loops. It is readable and easy to reason about.

(async function() {
  const asyncFunctions = [resolveInTwoSeconds, resolveInThreeSeconds, resolveInFiveSeconds];
  // outputs 2 after 2 seconds
  // outputs 3 after 5 seconds
  // outputs 5 after 8 seconds
  for (const asyncFn of asyncFunctions) {
    const result = await asyncFn();
    console.log(result);
  }
})();

Update: The approach below was the original one on the post, but after years of new experience, I've come to realize that this unnecessarily complicates things, and I was just hacking reduce to behave like a for loop. Advice: Just use for loops for this. Still keeping it here if you're interested

There's no native methods on Promise class that can do this quickly, but we can make use of Array.prototype.reduce method to achieve the goal.

(async function() {
  const asyncFunctions = [resolveInTwoSeconds, resolveInThreeSeconds, resolveInFiveSeconds];
  // outputs 2 after 2 seconds
  // outputs 3 after 5 seconds
  // outputs 5 after 8 seconds
  await asyncFunctions.reduce(async (previousPromise, nextAsyncFunction) => {
    await previousPromise;
    const result = await nextAsyncFunction();
    console.log(result);
  }, Promise.resolve());
})();

This is less straight-forward than the previous implementations, but I am going to write a separate post to explain this. Let's keep this post just for quick cheatsheets 😉.

4. Run async functions batch-by-batch, with each batch of functions executed in parallel

This is really helpful if you want to avoid hitting the rate limit of some API service. This makes use of the same concept in #3, where we have an array of promises resolved sequentially, combined with a two-dimensional array of promises and the use of Promise.all.

The key here is to build the collection of async functions in a two-dimensional array first. Once we have that, we can iterate over each collection of async functions and execute them in parallel, and use Promise.all to wait for each of those functions to complete. Until all of the promises in the current batch resolve, we are not going to process the next batch.

(async function() {
  const asyncFunctionsInBatches = [
    [resolveInTwoSeconds, resolveInTwoSeconds],
    [resolveInThreeSeconds, resolveInThreeSeconds],
    [resolveInFiveSeconds, resolveInFiveSeconds],
  ];

  // Outputs [2, 2] after two seconds
  // Outputs [3, 3] after five seconds
  // Outputs [5, 5] after eight seconds
  for (const currentBatch of asyncFunctionsInBatches) {
    const currentBatchPromises = currentBatch.map(asyncFn => asyncFn())
    const batchResults = await Promise.all(currentBatchPromises)
    console.log(batchResults)
  }
})();

Update: Again, the approach below was the original one on the post, but after years of new experience, I've come to realize that this unnecessarily complicates things, and I was just hacking reduce to behave like a for loop. Advice: Just use for loops for this. Still keeping it here if you're interested

Here's the full implementation of the above concept:

(async function() {
  const asyncFunctionsInBatches = [
    [resolveInTwoSeconds, resolveInTwoSeconds],
    [resolveInThreeSeconds, resolveInThreeSeconds],
    [resolveInFiveSeconds, resolveInFiveSeconds],
  ];

  // Outputs [2, 2] after two seconds
  // Outputs [3, 3] after five seconds
  // Outputs [5, 5] after eight seconds
  await asyncFunctionsInBatches.reduce(async (previousBatch, currentBatch, index) => {
    await previousBatch;
    console.log(`Processing batch ${index}...`);
    const currentBatchPromises = currentBatch.map(asyncFunction => asyncFunction())
    const result = await Promise.all(currentBatchPromises);
    console.log(result);
  }, Promise.resolve());
})();

Keep in mind that I'm building the batches of async functions through hard-coding here. In a real application, you might have a dynamic length of array returned from an API call or the likes, so you will have to split them yourselves. A quick implementation for this task:

const splitInBatch = (arr, batchSize) => {
  return arr.reduce((accumulator, element, index) => {
    const batchIndex = Math.floor(index / batchSize);
    if (Array.isArray(accumulator[batchIndex])) {
      accumulator[batchIndex].push(element);
    } else {
      accumulator.push([element]);
    }
    return accumulator;
  }, []);
}

// outputs [[1, 2, 3], [4, 5, 6]]
console.log(splitInBatch([1, 2, 3, 4, 5, 6], 3));

Or, you can also opt for libraries such as lodash to help you with this task.

import chunk from 'lodash.chunk';

// outputs [[1, 2, 3], [4, 5, 6]]
console.log(chunk([1, 2, 3, 4, 5, 6], 3));

5. Bonus Tip: Do not pass an async function to forEach

Remember, the difference between Array.prototype.map and Array.prototype.forEach is that the latter does not return the result of each iteration. If we pass async functions to forEach, we have no way of retrieving the returned promise to do anything useful with it. Unless you want to fire the async function and forget about it, passing async functions to forEach is never something you want to do.

Conclusion

There you go! That is all 5 cheatsheets on what to do and not to do with an array of Promises. I hope this has been useful to you all 😁, and please, please, let me know in the comments section if there's anything I ought to improve upon.

See you again!

DEV Community: Afif Sohaili

Bring your lost git commits back from the grave.

The background

git reflog to the rescue

Bringing back the lost commit from reflog the grave

Conclusion

Footnote 1

Footnote 2

How Does Your Team Do Tech Debt Analysis?

Dealing with Promises In an Array with async/await

1. Wait for all promises to complete with Promise.all

2. Wait for at least one promise to complete with Promise.race

3. Wait for all promises to complete one-by-one

4. Run async functions batch-by-batch, with each batch of functions executed in parallel

5. Bonus Tip: Do not pass an async function to forEach

Conclusion

`git reflog` to the rescue